Open Stack

rewriting is more expensive then getting the web server to return the right prefix. Is that an option? Usually its just a bug that needs a minor patch to fix.

Thanks,
Kevin
________________________________
From: Adam Young [ayoung at redhat.com]
Sent: Friday, August 05, 2016 3:06 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [keystone][tripleo] Federation, mod_mellon, and HA Proxy

On 08/05/2016 04:54 PM, Adam Young wrote:
On 08/05/2016 04:52 PM, Adam Young wrote:
Today I discovered that we need to modify the HA proxy config to tell it to rewrite redirects.  Otherwise, I get a link to

http://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse


Which should be https, not http.


I mimicked the lines in the horizon config so that the keystone section looks like this:


listen keystone_public
  bind 10.0.0.4:13000 transparent ssl crt /etc/pki/tls/private/overcloud_endpoint.pem
  bind 172.16.2.5:5000 transparent
  mode http
  redirect scheme https code 301 if { hdr(host) -i 10.0.0.4 } !{ ssl_fc }
  rsprep ^Location:\ http://(.*)<UrlBlockedError.aspx> Location:\ https://\1
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  server overcloud-controller-0 172.16.2.8:5000 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.2.6:5000 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.2.9:5000 check fall 5 inter 2000 rise 2

And.. it seemed to work the first time, but not the second.  Now I get

"Secure Connection Failed

The connection to openstack.ayoung-dell-t1700.test:5000 was interrupted while the page was loading."

Guessing the first success was actually a transient error.

So it looks like my change was necessary but not sufficient.

This is needed to make mod_auth_mellon work when loaded into Apache, and Apache is running behind  HA proxy (Tripleo setup).


There is no SSL setup inside the Keystone server, it is just doing straight HTTP.  While I'd like to change this long term, I'd like to get things working this way first, but am willing to make whatever changes are needed to get SAML and Federation working soonest.




Ah...just noticed the redirect is to :5000, not port :13000 which is the HA Proxy port.

OK, this is due to the SAML request:



<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_5089011BEBD0F6B82074F67E904F598D"
                    Version="2.0"
                    IssueInstant="2016-08-05T21:55:18Z"
                    Destination="https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml"<https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml>
                    Consent="urn:oasis:names:tc:SAML:2.0:consent:current-implicit"
                    ForceAuthn="false"
                    IsPassive="false"
                    AssertionConsumerServiceURL="https://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse"<https://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse>
                    >
    <saml:Issuer>https://openstack.ayoung-dell-t1700.test:5000/v3/mellon/metadata</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                        AllowCreate="true"
                        />
</samlp:AuthnRequest>


My guess is HA proxy is not passing on the proper, and the mod_auth_mellon does not know to rewrite it from 5000 to 13000




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160805/e69b9c37/attachment.html>