[openstack-dev] [keystone][tripleo] Federation, mod_mellon, and HA Proxy

Juan Antonio Osorio jaosorior at gmail.com
Sat Aug 6 06:48:23 UTC 2016


Adam, that should be fixed by https://review.openstack.org/#/c/341354/
which merged not too many days ago. Before that commit we had another
configuration which was already deprecated in keystone upstream.

On 6 Aug 2016 05:04, "Adam Young" <ayoung at redhat.com> wrote:

> On 08/05/2016 06:40 PM, Fox, Kevin M wrote:
>
> ------------------------------
> *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://(.*) <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
>
>
> "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"
>
>
> Well, I think in this case, the expense is not something to worry about:
> SAML is way more chatty than normal traffic, and the rewrite won't be a
> drop a in the bucket.
>
> I think the right thing to do is to get HA proxy top pass on the correct
> URL, including the port, to the backend, but I don't think it is done in
> the rsprep directive.  As John Dennis pointed out to me, the
> mod_auth_mellon code uses the apache ap_construct_url(r->pool,
> cfg->endpoint_path, r) where r is the current request record.  And that has
> to be passed from HA proxy to Apache.
>
> HA proxy is terminating SSL, and then calling Apache via
>
>
>   server overcloud-controller-0 172.16.2.8:5000 check fall 5 inter 2000
> rise 2
> and two others.  Everything appears to be properly translated except the
> port.
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 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/20160806/1a6eb8f6/attachment.html>


More information about the OpenStack-dev mailing list