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

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.

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.

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.

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.

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?

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 ?

@Sahil.Arora can you try to replicate?

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?

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

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; } "

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.

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.

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.

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

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

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.

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.

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.

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..

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

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.

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.

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."