Open Stack

On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick <d.w.chadwick at kent.ac.uk>
wrote:

> 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
>

So the "bug" is a misconfiguration, not an actual bug. The goal was to
trust and leverage httpd, not reimplement it and all it's extensions.


>
> 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141223/9c762afe/attachment.html>