Open Stack

Hi Adam

On 23/12/2014 17:34, Adam Young wrote:
> On 12/23/2014 11:34 AM, David Chadwick wrote:
>> Hi guys
>>
>> we now have the ABFAB federation protocol working with Keystone, using a
>> modified mod_auth_kerb plugin for Apache (available from the project
>> Moonshot web site). However, we did not change Keystone configuration
>> from its original SAML federation configuration, when it was talking to
>> SAML IDPs, using mod_shibboleth. Neither did we modify the Keystone code
>> (which I believe had to be done for OpenID connect.) We simply replaced
>> mod_shibboleth with mod_auth_kerb and talked to a completely different
>> IDP with a different protocol. And everything worked just fine.
>>
>> Consequently Keystone is broken, since you can configure it to trust a
>> particular IDP, talking a particular protocol, but Apache will happily
>> talk to another IDP, using a different protocol, and Keystone cannot
>> tell the difference and will happily accept the authenticated user.
>> Keystone should reject any authenticated user who does not come from the
>> trusted IDP talking the correct protocol. Otherwise there is no point in
>> configuring Keystone with this information, if it is ignored by Keystone.
> The IDP and the Protocol should be passed from HTTPD in env vars. Can
> you confirm/deny that this is the case now?

What is passed from Apache is the 'PATH_INFO' variable, and it is set to
the URL of Keystone that is being protected, which in our case is
/OS-FEDERATION/identity_providers/KentProxy/protocols/saml2/auth

There are also the following arguments passed to Keystone
'wsgiorg.routing_args': (<routes.util.URLGenerator object at
0x7ffaba339190>, {'identity_provider': u'KentProxy', 'protocol': u'saml2'})

and

'PATH_TRANSLATED':
'/var/www/keystone/main/v3/OS-FEDERATION/identity_providers/KentProxy/protocols/saml2/auth'

So Apache is telling Keystone that it has protected the URL that
Keystone has configured to be protected.

However, Apache has been configured to protect this URL with the ABFAB
protocol and the local Radius server, rather than the KentProxy IdP and
the SAML2 protocol. So we could say that Apache is lying to Keystone,
and because Keystone trusts Apache, then Keystone trusts Apache's lies
and wrongly thinks that the correct IDP and protocol were used.

The only sure way to protect Keystone from a wrongly or mal-configured
Apache is to have end to end security, where Keystone gets a token from
the IDP that it can validate, to prove that it is the trusted IDP that
it is talking to. In other words, if Keystone is given the original
signed SAML assertion from the IDP, it will know for definite that the
user was authenticated by the trusted IDP using the trusted protocol

regards

David

> 
> On the Apache side we are looking to expand the set of variables set.
> http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables
> 
> 

The original SAML assertion
> 
> mod_shib does support Shib-Identity-Provider :
> 
> 
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess#NativeSPAttributeAccess-CustomSPVariables
> 
> 
> Which should be sufficient: if the user is coming in via mod_shib, they
> are using SAML.
> 
> 
> 
>>
>> BTW, we are using the Juno release. We should fix this bug in Kilo.
>>
>> As I have been saying for many months, Keystone does not know anything
>> about SAML or ABFAB or OpenID Connect protocols, so there is currently
>> no point in configuring this information into Keystone. Keystone is only
>> aware of environmental parameters coming from Apache. So this is the
>> protocol that Keystone recognises. If you want Keystone to try to
>> control the federation protocol and IDPs used by Apache, then you will
>> need the Apache plugins to pass the name of the IDP and the protocol
>> being used as environmental parameters to Keystone, and then Keystone
>> can check that the ones that it has been configured to trust, are
>> actually being used by Apache.
>>
>> regards
>>
>> David
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>