By: Russell Fitzpatrick user 15 May 2020 at 12:45 p.m. CDT

24 Responses
Russell Fitzpatrick gravatar
I have install version 4.1.0 Final I'm having the same problem as the user in this post: https://support.gluu.org/authentication/8218/cant-register-supergluu-devices/ Where as I can't get Super Gluu to register devices. I am trying to use casa.. I applied the fix I've updated the certificate, and so fourth.. now I can't login to case give error : ``` An error occurred during authorization step com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "error" (class org.gluu.oxd.common.response.GetClientTokenResponse), not marked as ignorable (4 known properties: "expires_in", "scope", "refresh_token", "access_token"]) at [Source: (ByteArrayInputStream); line: 1, column: 11] (through reference chain: org.gluu.oxd.common.response.GetClientTokenResponse["error"]) ``` I'm so stressed.. I've been playing with this for a week now trying to get this all configured. I can get otp google authenticat to work.. I've got cache refresh to work.. I don't know much about this technology, I'm really trying to learn.. I've updated the certificate for the Gluu server, and it works well. I've also updated the certificate for the oxd sever, but once I do I'm it gives me an error in casa.. though I can go the the port 8443 and the health-check says running. in updating the certificate I've added it to the trust store and all it just doesn't work I keep getting casa errors. So I reverted back. also I've installed on a multitude of servers. I've got a vsphere environment I'm using, I've installed on Centos versions 7, 8, and 8.1. 8.1 will not authenticate with otp authenticator, and I tried all the time zone fixes I was able to find.. which also reminds me.. even in centos 7 or 8.0 and 8.1 for example when I look at the cash refresh logs the time is off by hours.. but the system time is fine.. in both the container and the local vm hosting it. I see in posts that version 4.2 is to be released soon, is there a way I could try it early or get ahold of it. I'm using the default install where I'm having the install install oxd locally should I have this installed on another server ?.. guys i really need some guidance.

By Michael Schwartz staff 18 May 2020 at 12:22 p.m. CDT

Michael Schwartz gravatar
Does your Gluu Server have an Internet accessible IP address? This is a requirement for Super Gluu.

By Russell Fitzpatrick user 18 May 2020 at 3:19 p.m. CDT

Russell Fitzpatrick gravatar
So Michael, can you elaborate on this.. are you asking if it has a public ip address or if it can access the internet from a private address.. I have mine setup with a private address which has access to the internet, I have nginx as my reverse proxy to the gluu server. I then updated the http certificitate with a letsencrypt certificate.. I have it registered with go daddy so I point sso.xyz.com to my public address.. I can use google authenticate to login, I've also configured cache refresh.. I hope that answers you question. I have a few builds one on 7.9 centos and 8.0, I trashed the 8.1 cuz google authenticate just wouldn't work.. something with the time zone.

By Russell Fitzpatrick user 18 May 2020 at 3:34 p.m. CDT

Russell Fitzpatrick gravatar
I'm now getting this error after applying the fix as mentioned above An error occurred Gluu Casa did not start properly. Contact your admin.

By Aliaksandr Samuseu staff 19 May 2020 at 6:42 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Russel. Basically, the problem you're facing is how to point an app running on your smartphone to your Gluu Server instance (you need the Supergluu app to be able to connect to TCP port 443 of your Gluu Server). What Michael meant is that if your Gluu Server is running on some machine that is accessible from the Internet, it's much simpler to achieve (you still may need to add FQDN of your Gluu Server to your phone's hosts file if the FQDN isn't resolvable via DNS). If your Gluu host doesn't have public ip address, you may need to invest additional efforts into configuring some kind of port forwarding for port 443 as well. Hope that makes it more clear.

By Russell Fitzpatrick user 20 May 2020 at 1:42 p.m. CDT

Russell Fitzpatrick gravatar
well yes I do have the server accessible via ssl on port 443 it's all open on the network. Guys I have a full infrastructure and i've been in it for over 25 years mainly on the microsoft, and virtual (vmware) realm.. linux is somewhat new to me.. I'm still learning but I've been a sr. System Engineer for quite some time. the problem is just as the person that I mentioned in my first post, I applied the fix in the article and now I'm getting the other error.. I have dns servers, public dns, nginx wap.. blah blah.. I think the underlying infrastructure is good.

By Michael Schwartz staff 20 May 2020 at 2:07 p.m. CDT

Michael Schwartz gravatar
We're just covering the basics. The error is from oxd, which is the client middleware used by Casa to perform OAuth and OpenID operations. Not sure where they are off the top of my head, but check the oxd docs: https://gluu.org/docs oxd itself has a lot which may provide more information. Also, important to check the Gluu Server oxAuth logs (/opt/gluu/jetty/oxauth/logs). One more random thing to check: make sure the clock is correct. Are you using NTP on the server? Are you in sync?

By Russell Fitzpatrick user 20 May 2020 at 5:37 p.m. CDT

Russell Fitzpatrick gravatar
I used the standard install, where as I allowed it to install everything at once, I don't have an external oxd server should I ? guys I followed all of the instructions you have posted and googled multiple sources for the install. I'm installing on either centos 7 or 8.. should I not install on that platform ? Something is bad with the install/code.. I've been working on this for 2 almost 3 weeks now. I've gone over all the stuff before reaching out to you. yes my servers time is in sync. that was one of the first articles I found. like i said on 8.1 doesn't work period.. SuperGluu or OTP simple authenticator. I'm usually really good at figuring these things out.. it takes a lot for me to reach out for help, and if / when i do .. then it's usually a bug in the system. because I've done my research and read almost all articles, and tried multiple fixes, formatted and rebuilt.. and such.. When would 4.2 be released ? again is there a link I can download and test. Do a fresh build of centos7 or 8.0 (not 8.1), say yes to all of the questions on installing casa, oxd, ect.. (that is what I did), replace the httpd cert, open firewall ports required and try and use Supergluu.. it will not work. it would be different if I had the system for years and did plenty of upgrades, or had custom stuff added.. or even configured the one that I installed but this is a fresh build from the Centos ISO and using your install docs for v4.1 to install, i did both updating after install and not updating to see if it would work. It just plain doesn't work out of the box on a fresh install. what have I done wrong ?

By Michael Schwartz staff 20 May 2020 at 6:47 p.m. CDT

Michael Schwartz gravatar
@Sahil.Arora can you try to replicate?

By Sahil Arora staff 21 May 2020 at 10:20 a.m. CDT

Sahil Arora gravatar
Hi Russell, I will try to replicate this issue at my end in the similar environment to yours. I'll be using Gluu 4.1 with Casa and Nginx as reverse proxy to Gluu. Please me know for any other consideration?

By Michael Schwartz staff 21 May 2020 at 11:40 a.m. CDT

Michael Schwartz gravatar
``` I have nginx as my reverse proxy to the gluu server ``` Please paste your nginx config here. You probably missed a proxy config.

By Russell Fitzpatrick user 21 May 2020 at 1:56 p.m. CDT

Russell Fitzpatrick gravatar
Hey Michael, So I'll give you run down of my setup.. nginx yes i have but I can use it without it.. I have a Microsoft AD domain and I run DNS through my AD Servers. I have a Primary zones : thadeeze.local - where I run all of my internal stuff.. thadeeze.com - where I run my public stuff. and a few others for the websites I host. I have two internet services to my home: 1) fiber 1gb connections for home use 2) 50 gb down 25 up for my business purposes. I have two separate routers for both. When I test externally I just change my wifi to my home internet and test. When I test internally I point my wireless to my business link. all of my client machines point their DNS to my two DC's (domain controllers) if on the business side, or my dc on my home side if connected to home wireless. Home and business have different cidr blocks. I don't use host files.. they are the devil... LOL so internally on the business side I don't use my nginx server to connect to any of my resources. So even if my nginx configs were wrong I would not make a difference internally because they point to the servers directly. I have opened up firewall ports on my cent servers to accommodate the what is needed by the gluu configs. port 80, 443, 8443.. etc. but when things come in from the public address it goes through my nginx servers. internally I get the same response as I get when I go publically. so my test servers are: sso.thadeeze.com - is running centos 7 mfa.thadeeze.com - is running cent0s 8 nginx config is : Server configs: " #Gluu MFA Server server { listen 80; \n; server_name mfa.thadeeze.com www.mfa.thadeeze.com; rewrite ^/(.*)$ https://$host$request_uri? permanent; } server { listen 443 ssl; server_name mfa.thadeeze.com; ssl_certificate /var/www/certs/mfa.thadeeze.com.pem; ssl_certificate_key /var/www/certs/mfa.thadeeze.com.key; access_log /var/www/weblogs/mfa_thadeeze_com.log; location / { proxy_redirect off; proxy_set_header Host mfa.thadeeze.com; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; # This is necessary to pass the correct IP to be hashed real_ip_header X-Real-IP; proxy_pass https://gluu_mfa; include /etc/nginx/naxsi.rules; } } #Super Gluu OXD MFA Server server { listen 8443 ssl; server_name mfa.thadeeze.com; ssl_certificate /var/www/certs/mfa.thadeeze.com.pem; ssl_certificate_key /var/www/certs/mfa.thadeeze.com.key; access_log /var/www/weblogs/mfa_thadeeze_com.log; location / { proxy_redirect off; proxy_set_header Host mfa.thadeeze.com; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; # This is necessary to pass the correct IP to be hashed real_ip_header X-Real-IP; proxy_pass https://gluu_oxd_mfa; include /etc/nginx/naxsi.rules; } } #Gluu MFA SSO Server server { listen 80; server_name sso.thadeeze.com www.sso.thadeeze.com; rewrite ^/(.*)$ https://$host$request_uri? permanent; } server { listen 443 ssl; server_name sso.thadeeze.com; ssl_certificate /var/www/certs/sso_thadeeze_com.pem; ssl_certificate_key /var/www/certs/sso_thadeeze_com.key; access_log /var/www/weblogs/sso_thadeeze_com.log; location / { proxy_redirect off; proxy_set_header Host sso.thadeeze.com; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; # This is necessary to pass the correct IP to be hashed real_ip_header X-Real-IP; proxy_pass https://gluu_sso; include /etc/nginx/naxsi.rules; } } #Super Gluu OXD MFA Server server { listen 8443 ssl; server_name sso.thadeeze.com; ssl_certificate /var/www/certs/sso_thadeeze_com.pem; ssl_certificate_key /var/www/certs/sso_thadeeze_com.key; access_log /var/www/weblogs/sso_oxd_thadeeze_com.log; location / { proxy_redirect off; proxy_set_header Host sso.thadeeze.com; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; # This is necessary to pass the correct IP to be hashed real_ip_header X-Real-IP; proxy_pass https://gluu_oxd_sso; include /etc/nginx/naxsi.rules; Upstream configs: upstream gluu_mfa { hash $remote_addr consistent; server 10.10.xxx.xxx:443; } upstream gluu_oxd_mfa { ip_hash; server 10.10.xxx.xxx:8443 weight=100 max_fails=5 fail_timeout=300; } upstream gluu_sso { hash $remote_addr consistent; server 10.10.xxx.xxx:443; } upstream gluu_oxd_sso { ip_hash; server 10.10.xxx.xxx:8443 weight=100 max_fails=5 fail_timeout=300; } "

By Michael Schwartz staff 21 May 2020 at 2:04 p.m. CDT

Michael Schwartz gravatar
I'm closing this issue. The network config is outside the scope of community support. I'd suggest using a public address on the Gluu Server... see if it works. At that point, work backwards from how you are routing the inbound traffic. If Super Gluu is too hard to get working due to the notification routing issue, consider using FIDO U2F tokens. You can use https://krypt.co for example, which may be easier if you want a mobile solution.

By Russell Fitzpatrick user 21 May 2020 at 2:05 p.m. CDT

Russell Fitzpatrick gravatar
Like I said in my previous post, build a centos server 7 or 8.0 from scratch.. (spin up a vm and install from cd) do a yum update all or dnf update all.. then do the steps you have posted for the v4.1 server install typing yes to install everything casa, oxd.. etc.... open firewall ports. update the httpd cert or update both httpd and oxd cert and it won't work out of the box. Just spin up a machine and test that.

By Russell Fitzpatrick user 21 May 2020 at 2:07 p.m. CDT

Russell Fitzpatrick gravatar
It has nothing to do with a public address being on the server, that's a cop out. I have 5 public addresses I gave it one of my public address and I still had the same issue. Like I said if I bring this problem to you guys it isn't because I haven't exhausted all options it's because a bug in code or installation.

By Russell Fitzpatrick user 21 May 2020 at 2:13 p.m. CDT

Russell Fitzpatrick gravatar
I'd be interested to see what @Sahil.Arora has found.

By Michael Schwartz staff 21 May 2020 at 2:34 p.m. CDT

Michael Schwartz gravatar
We've tested the code on a publicly accessible server, and it works fine. We don't have time to troubleshoot network issues.

By Sahil Arora staff 21 May 2020 at 2:36 p.m. CDT

Sahil Arora gravatar
Hi Russell, I have tested on publicly accessible server with a letsencrypt certificate and It's working as expected. I was able to register and use Super Gluu.

By Russell Fitzpatrick user 21 May 2020 at 3:07 p.m. CDT

Russell Fitzpatrick gravatar
ok what cent os version did you use ? so you are saying that if a person has a dev environment, that has full internet access where the server has a internal ip address that is served from a dns server or host files.. that it won't work ? you are saying this server has to be on a public ip (which I've tested) ? Does it have to be a multi homed server ? did you install a new setup? I don't have network issues.. I run ms rdsweb, view servers, web sites.. all for my lab and learning. I'm not trying to be a A$$ I like your product and want to test and use it. but just needed some guidance. I just want to know where the problem is. guys.. that's all.

By Michael Schwartz staff 21 May 2020 at 3:37 p.m. CDT

Michael Schwartz gravatar
There are two things I would look into... when you scan the QR code, what is the hostname? Try decoding the QR code. Also, the Gluu Server is going to poll for a push notification event. Are you able to receive the push notification? There are limits to community support. In general, we want to follow-up on mainstream deployment scenarios. Gluu Server deployed on home network is not something we see a lot. Also, keep in mind that the code is free, the binaries are free, Super Gluu is free... we do some basic community support. So we're doing our best for the community. But enterprise support is the one thing we sell--it's the candy in the candy store. So we have limited time for deep debugging of community issues. If you find a solution, post it here for the benefit of others. Or let us know if there are some docs we could update to make the solution more clear. That's how you can do your part for the open source community.

By Russell Fitzpatrick user 21 May 2020 at 5:13 p.m. CDT

Russell Fitzpatrick gravatar
Sorry for the delay, (girl made me got to the store). yes my network is in my home, but most people don't have the horsepower I have running out of my home.. like I said this is what I do for a living.. my home is treated like an enterprise, I don't cut corners and don't band-aid stuff. My customers don't deserve that. To answer your question no I'm not getting the notifications it's giving me the error: "Fido U2F response was rejected." so I applied the fix stated on this site article: https://support.gluu.org/authentication/8218/cant-register-supergluu-devices/ I had confirmed that the qrcode was decoded to that gluu application I also confirmed that the otp using google authenticate was working and I also got the cache refresh working to authenticate to my active directory domain. I also want to help the community, I don't want anyone going through this.. if I can't get this thing to work (my nickname by my co-workers is the "Wizard"), there's a problem. so give me about an hour I'm going to setup an new build on the a public ip again..

By Russell Fitzpatrick user 21 May 2020 at 11:34 p.m. CDT

Russell Fitzpatrick gravatar
So update.. Well as I stated it doesn't work.. i have it on a public IP no nginx as a reverse proxy to it. my asav isn't infront of it.. and it is actually worse that what is was without it.. I installed Centos 7 for this test then used the your 4.1 doc for the install.. I've not done cache refresh, I've or any other configs but the basic to get casa setup and to present otp and super gluu for options of for 2fa authentication. Neither SuperGluu nor OTP is working... which i'm surprised that otp isn't because usually that works no problem, especially on centos 7. This time it's saying failed to get fido2 metadata.. so that is also a new error. so hey guys if you want to check it out: sso7.thadeeze.com username=gluu-support password=letmein

By Michael Schwartz staff 22 May 2020 at 11:37 a.m. CDT

Michael Schwartz gravatar
One weird thing I see in your config is that SCIM support was disabled? Casa uses SCIM... Did you disable this? You might need to re-enable and restart.

By Russell Fitzpatrick user 22 May 2020 at 3:29 p.m. CDT

Russell Fitzpatrick gravatar
So Michael, No That was a fresh install as I was telling you.. I did nothing but install centos7. Did a yum update all, then went and installed vi the v4.1 instructions.. that was fresh out of the box.. I then went and enabled the script otp, and supergluu.. did the touch .administrable. Created your user. this is my point that @Sahil.Arora did not replicate the problem instead used a working gluu server that you guys have running.

By Russell Fitzpatrick user 22 May 2020 at 3:31 p.m. CDT

Russell Fitzpatrick gravatar
I enabled scim and now I'm getting the same error as I was in my original post and otp still isn't working. error: "Fido U2F response was rejected."