By: Gregg Cameron user 04 Nov 2019 at 1:34 p.m. CST

18 Responses
Gregg Cameron gravatar
I've successfully installed version 3.1.6 on AWS with this same setup, but I'd prefer to use version 4.0 for the improvements with passport. I've installed version 4.0 on Ubuntu 16.04 on AWS. I installed all components and when asked for ip address I used the internal ip address. We have a public DNS of ssostaging.hypersign.net which points to a load balancer on AWS which forwards to the actual server. The flow is ssostaging.hypersign.net gets 302 to ssostaging.hypersign.net/identity/ which gets a 200 to ssostaging.hypersign.net/identity/home.htm which gets a 302 and redirects to https://0.0.1.187/identity/login.htm which of course doesn't exist and I cannot find that ip address anywhere in the gluu-server container. Another oddity I noticed was when hitting https://ssostaging.hypersign.net/identity/home.htm the response header returns a Location with Https://443/identity/login.htm. Any help you could provide would be greatly appreciated and if there is any more info I can give you please let me know.

By Aliaksandr Samuseu staff 05 Nov 2019 at 2:51 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Gregg. Could you share your Apache config from this instance? Should be at this location: `/etc/apache2/sites-enabled/https_gluu.conf` Also, what is output of `# hostname` and `# ifconfig` **from inside container** there (or `# ip addr` if the later is not present)?

By Gregg Cameron user 05 Nov 2019 at 3:14 p.m. CST

Gregg Cameron gravatar
Apache Config ``` <VirtualHost *:80> ServerName ssostaging.hypersign.net Redirect / https://ssostaging.hypersign.net/ DocumentRoot "/var/www/html/" </VirtualHost> <VirtualHost *:443> DocumentRoot "/var/www/html/" ServerName ssostaging.hypersign.net:443 LogLevel debug SSLEngine on SSLProtocol -all +TLSv1.1 +TLSv1.2 SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK SSLCertificateFile /etc/certs/httpd.crt SSLCertificateKeyFile /etc/certs/httpd.key # SetEnv proxy-nokeepalive 1 SetEnv proxy-initial-not-pooled 1 Timeout 60 ProxyTimeout 60 # Security headers # Header always append X-Frame-Options SAMEORIGIN Header always set X-Xss-Protection "1; mode=block" Header always set X-Content-Type-Options nosniff # Header always set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://ssostaging.hypersign.net" Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header edit Set-Cookie ^((?!session_state).*)$ $1;HttpOnly SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Unset X-ClientCert to make sure that we not get certificate in request RequestHeader unset X-ClientCert # Turn off support for true Proxy behaviour as we are acting as a transparent proxy ProxyRequests Off # Turn off VIA header as we know where the requests are proxied ProxyVia Off # Turn on Host header preservation so that the servlet container # can write links with the correct host and rewriting can be avoided. ProxyPreserveHost On # Preserve the scheme when proxying the request to Jetty RequestHeader set X-Forwarded-Proto "https" env=HTTPS Header unset ETag FileETag None RedirectMatch ^(/)$ /identity/ # Set the permissions for the proxy <Proxy *> AddDefaultCharset off Order deny,allow Allow from all </Proxy> <Location /idp> ProxyPass http://localhost:8086/idp retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /identity> ProxyPass http://localhost:8082/identity retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /cas> ProxyPass http://localhost:8083/cas retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /oxauth-rp> ProxyPass http://localhost:8085/oxauth-rp retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /passport> ProxyPass http://localhost:8090/passport retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /casa> ProxyPass http://localhost:8099/casa retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /oxauth> ProxyPass http://localhost:8081/oxauth retry=5 connectiontimeout=60 timeout=60 # Header set Access-Control-Allow-Origin "*" Order deny,allow Allow from all </Location> <LocationMatch /oxauth/auth/cert/cert-login> SSLVerifyClient optional_no_ca SSLVerifyDepth 10 SSLOptions -StdEnvVars +ExportCertData # Forward certificate to destination server RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s </LocationMatch> ProxyPass /.well-known/openid-configuration http://localhost:8081/oxauth/.well-known/openid-configuration ProxyPass /.well-known/simple-web-discovery http://localhost:8081/oxauth/.well-known/simple-web-discovery ProxyPass /.well-known/webfinger http://localhost:8081/oxauth/.well-known/webfinger ProxyPass /.well-known/uma2-configuration http://localhost:8081/oxauth/restv1/uma2-configuration ProxyPass /.well-known/fido-configuration http://localhost:8081/oxauth/restv1/fido-configuration ProxyPass /.well-known/fido2-configuration http://localhost:8081/oxauth/restv1/fido2/configuration ProxyPass /.well-known/fido-u2f-configuration http://localhost:8081/oxauth/restv1/fido-configuration ProxyPass /.well-known/scim-configuration http://localhost:8082/identity/restv1/scim-configuration </VirtualHost> ``` ifconfig ``` eth0 Link encap:Ethernet HWaddr 22:00:0a:9e:c5:2f inet addr:10.158.197.47 Bcast:10.158.197.255 Mask:255.255.255.0 inet6 addr: fe80::2000:aff:fe9e:c52f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172150 errors:0 dropped:0 overruns:0 frame:0 TX packets:148900 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24090684 (24.0 MB) TX bytes:39077515 (39.0 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:100610 errors:0 dropped:0 overruns:0 frame:0 TX packets:100610 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:32651901 (32.6 MB) TX bytes:32651901 (32.6 MB) ``` hostname = ssostaging.hypersign.net

By Aliaksandr Samuseu staff 05 Nov 2019 at 3:19 p.m. CST

Aliaksandr Samuseu gravatar
Thanks, Gregg, it seems fine to me. I guess we need to double-check the whole installation process for AWS. I'll get back to you soon.

By Aliaksandr Samuseu staff 06 Nov 2019 at 10:20 a.m. CST

Aliaksandr Samuseu gravatar
Hi, Gregg. My first install of CE 4.0 in Xenial-based AWS instance worked just fine. I'll record a screencast of my next attempt and share with you, so you could compare your steps with mine. Just to be sure: when installing, you were following [this doc](https://gluu.org/docs/ce/4.0/installation-guide/install-ubuntu/) yourself, the part marked "For Ubuntu 16.04.x", correct?

By Gregg Cameron user 06 Nov 2019 at 11:53 a.m. CST

Gregg Cameron gravatar
That is the document I followed. Just trying to think of anything that may be different between our environment and yours. One difference is that I didn't do any of the static ip related setup in the VM Setup section given that we have an ELB in front of the server and the DNS points to that load balancer which obviously has a static ip already. I did assign an elastic ip to the server though that's probably not needed either. During the execution of setup.py I did specify the AWSi nternal ip as the ip and ssostaging.hypersign.net as the hostname. The only other thing I can think of is that our server is running in the classic EC2 and not a VPC.

By Aliaksandr Samuseu staff 06 Nov 2019 at 12:04 p.m. CST

Aliaksandr Samuseu gravatar
>During the execution of setup.py I did specify the AWSi nternal ip as the ip Do you mean you had to actually type in another ip address instead of the one it suggested as default one? It's believed that it's better to just confirm the default ip address `setup.py` offers to you. I personally have never actually tried to change it, and I'm not sure setup on multi-homed or multi-ip host is tested very thoroughly. I would say, ideally, you should install on a vm with a single network interface which has just one ip address assigned, anything else may not work as expected.

By Gregg Cameron user 06 Nov 2019 at 12:09 p.m. CST

Gregg Cameron gravatar
I did not have to type in another ip address. The default was the internal IP from AWS

By Gregg Cameron user 06 Nov 2019 at 12:14 p.m. CST

Gregg Cameron gravatar
Maybe the ELB is causing the issue? Based on the flow of redirects it seems like it's losing the IP address as somepoint and trying to route to just port 443 which you can't do so AWS is inserting the bogus ip 0.0.1.187. I'm not, by any means, a sys admin so a lot of this is foreign to me.

By Aliaksandr Samuseu staff 06 Nov 2019 at 12:40 p.m. CST

Aliaksandr Samuseu gravatar
In our previous setups we didn't have issues with ELB. But it turns out in my recent test ELB wasn't a part of the setup. I'll re-try installation with it added now.

By Aliaksandr Samuseu staff 07 Nov 2019 at 1:14 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Gregg. One thing I still can't figure out - how exactly did you configure your Load Balancer in AWS? What type did you select, and why did you need it at all? Do you have several Gluu Server instances running behind it, perhaps?

By Gregg Cameron user 08 Nov 2019 at 8:13 a.m. CST

Gregg Cameron gravatar
We use the load balancer because that's where we house our SSL certs. We have to use the classic load balancer since our server is EC2 and not VPC. It's listening on ports 80 and 443. So our DNS, ssostaging.hypersign.net is pointed to the load balancer. That connection is HTTPS. We only have one gluu server so the ELB hands off to it. Let me know if you need more information on how it's setup.

By Gregg Cameron user 08 Nov 2019 at 9:12 a.m. CST

Gregg Cameron gravatar
We don't have to use the load balancer, it's just normally how we set things up. I took the server out of the load balancer, uninstalled everything, rebooted and then reinstalled. I'm still getting errors. If you could post that video that might help.

By Gregg Cameron user 08 Nov 2019 at 10:06 a.m. CST

Gregg Cameron gravatar
I was able to get this to work without the ELB. I had typo'd the hostname in my local hosts file.

By Aliaksandr Samuseu staff 08 Nov 2019 at 10:23 a.m. CST

Aliaksandr Samuseu gravatar
Hi, Gregg. Please find the video attached. This is installation done at Xenial EC2 (VPC, not Classic, as we don't have ability to create the later, due to limitations of our AWS account). It's not behind any LB, just an elastic IP assigned EC2 instance.

By Aliaksandr Samuseu staff 08 Nov 2019 at 10:24 a.m. CST

Aliaksandr Samuseu gravatar
>I was able to get this to work without the ELB. I had typo'd the hostname in my local hosts file. Oh, I see. That makes sense. So, does it also work when you put it behind LB now? Or the original issue still persists?

By Gregg Cameron user 08 Nov 2019 at 11:03 a.m. CST

Gregg Cameron gravatar
I will check and let you know, but I doubt it since we had the DNS ssostaging.hypersign.net registered it wouldn't have been needed in my local hosts file.

By Aliaksandr Samuseu staff 11 Nov 2019 at 3:28 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Gregg. Any progress with making it work?

By Gregg Cameron user 12 Nov 2019 at 9:30 a.m. CST

Gregg Cameron gravatar
Hey Aliaksandr, I'm still in the same spot as before. It works without the load balancer, but once I turn on the ELB it breaks. I can continue to go ahead and get the rest of my stuff setup for testing without the ELB. We would prefer to be able to use the ELB, but if worse comes to worst we can install the cert on the server bypass the ELB. Thanks! -Gregg