Open Stack

On 08/07/2016 11:16 PM, Adam Young wrote:
> On 08/06/2016 08:44 AM, John Dennis wrote:
>> On 08/05/2016 06:06 PM, Adam Young wrote:
>>>> 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"
>>>
>>> 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"
>>>                     >
>>>
>>> <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
>>
>> You can't change the contents of a SAML AuthnRequest, often they are
>> signed. Also, the AssertionConsumerServiceURL's and other URL's in
>> SAML messages are validated to assure they match the metadata
>> associated with EntityID (issuer). The addresses used inbound and
>> outbound have to be correctly handled by the proxy configuration
>> without modifying the content of the message being passed on the
>> transport.
>>
> Got a a little further by twerking HA proxy settings.  Added in
>
>   redirect scheme https code 301 if { hdr(host) -i 10.0.0.4 } !{ ssl_fc }
>   rsprep ^Location:\ http://(.*) Location:\ https://\1
>
> whicxh tells HA proxy to translate Location headers (used in redirects)
> from http to https.
>
>
> As of now, it looks good up until the response comes back from the IdP
> and mod mellon rejects it.  I think this is due to Mellon issuing a
> request for http://<hostname>:<port>  but it gets translated through the
> proxy as https://<hostname>:<port>.
>
>
> mod_auth_mellon is failing the following check in auth_mellon_handler.c
>
>
>   url = am_reconstruct_url(r);
>
>   ...
>
>   if (response->parent.Destination) {
>
>         if (strcmp(response->parent.Destination, url)) {
>             ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
>                           "Invalid Destination on Response. Should be: %s",
>                           url);
>             lasso_login_destroy(login);
>             return HTTP_BAD_REQUEST;
>         }
>     }
>
> It does not spit out the parent.Destination value, but considering I am
> seeing http and not https in the error message, I assume that at least
> the protocol does not match.  Full error message at the bottom.
>
> Assuming the problem is just that the URL is http and not https,   I
> have an approach that should work.  I need to test it out, but want to
> record it here, and also get feedback:
>
> I can clone the current 10-keystone_wsgi_main.conf which listens for
> straight http on port 5000.  If I make a file
> 11-keystone_wsgi_main.conf  that listens on port 13000 (not on the
> external VIP)  but that enables SSL, I should be able to make HA proxy
> talk to that port and re-encrypt traffic, maintaining the 'https://'
> protocol.
>
>
> However, I am not certain that Destination means the SP URL.  It seems
> like it should mean the IdP.  Further on in auth_mellon_handler.c
>
>   destination_url = lasso_provider_get_metadata_one(
>         provider, "SingleSignOnService HTTP-Redirect");
>     if (destination_url == NULL) {
>         /* HTTP-Redirect unsupported - try HTTP-POST. */
>         http_method = LASSO_HTTP_METHOD_POST;
>         destination_url = lasso_provider_get_metadata_one(
>             provider, "SingleSignOnService HTTP-POST");
>     }
>
> Looking in the metadata, it seems that this value should be:
>
>  <SingleSignOnService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
> Location="https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml"
> />
>
> So maybe something has rewritten the value used as the url ?
>
>
> Here is the full error message
>
>
> Invalid Destination on Response. Should be:
> http://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse,
> referer:
> https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml?SAMLRequest=nZJba%2BMwEEb%2FitG7I%2BXi1Igk4OYCge5S0m4f%2BlKEM2lFLcmrGWc3%2F35HDu22D22hIDCMZ%2FTpHGmGxjWtrjp68jv43QFS9tc1HnX%2FYy666HUwaFF74wA11fqm%2BnGlRwOl2xgo1KERb0Y%2BnzCIEMkGL7Ltai4e1LoYq%2FFoXapJWU2GhSouN5vhelpNyqIcX2xEdgcRuX8ueJyHEDvYeiTjiUtqOM1VmavprRppXkVxL7IVM1hvqJ96ImpRS2n34MnSaWBOofOP%2BR6aJqfhhVID4n5pWICMYBqHMrSQEupn%2BQIoE5nIlsEjpODPEOtzk667GPmbW9c2trYksk2INfSm5%2BJgGoTEc81K7BFeK9WLoRTWOYg3EI%2B2hl%2B7q%2F80ryf8AEcXSil5HEvH9eBlG5B2gG06mljMEo3uVcbFd7d0QGZvyMzk291m5%2Bf0k61sV9eBwU8J25kvpKWK3eeHvlVTNB4ty2MdHPZnyRdDrIhiB0IuzpHvH%2B3iHw%3D%3D&RelayState=http%3A%2F%2Fopenstack.ayoung-dell-t1700.test%3A5000%2Fv3%2Fauth%2FOS-FEDERATION%2Fwebsso%2Fsaml2%3Forigin%3Dhttp%3A%2F%2Fopenstack.ayoung-dell-t1700.test%2Fdashboard%2Fauth%2Fwebsso%2F&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=oJzAwE7ma3m0gZtO%2FvPQKCnk18u4OsjKcRQ3wiDu7txUGiPr4Cc9XIzKIGwzSGPSaWi8j1qbN76XwdNICOk!
>
> HI5RsTdeS2Yeufw5Q5Ahol5cJHGEQOKa84iMzxkW9OtWgoYZnnXH3n2SCZkhLebabvJ72wfxskZ9iJ9JlVogHO8V%2BXUZ891sX1Rpm3UKHEn1fpW7tlGkJsWmnQoa3H8n%2Fr5%2BdiZR1g8iDTZVQs7A4wUEA0Ph%2FayS6MnSF%2BrSCRfgcqXGReKbIM6RxTznbV%2BO2U%2FXfuf%2FXT5x5h9accEv2Dsy8jej0uWEPJLGB3NfKUuwQmZCU5UkR%2BIqVHboUK6K8lg%3D%3D

The Destination attribute in the root SAML XML message is a security 
check to assure only the intended recipient processes the message. It's 
only meaningful (and required) when the message is signed (as it should 
be). Destination attributes occur in both message directions, e.g. 
requests and responses.

First of all recall that both the SP and IdP know about each other 
because they've exchanged metadata. Inside that metadata are URL's which 
are valid endpoints for specific messages.

When one side of the pair (SP, IdP) wants to send a message they lookup 
the appropriate URL in the metadata. That URL is set as the Destination 
attribute in the message. The receiver of the message is *required* to 
verify the endpoint the message was received on matches the Destination 
attribute, in other words it *is the intended recipient*. If they do not 
match the message *must* be discarded.

It's a shame Mellon does not log the Destination and the endpoint it was 
received on, that's something I can fix.

In lieu of that I would look at the SP metadata and see what the 
Location attribute is for the AssertionConsumerService using the 
HTTP-POST binding because that is what the IdP should be setting as the 
Destination attribute. The URL the SP (Mellon) received the message on 
should be logged in the access log, this is what Mellon is comparing to 
the Destination. I suspect something in the proxy configuration is 
modifying the URL of the Idp -> SP message.

-- 
John