Open Stack

If I understand the bug fix correctly, it is firmly tying the URL to the
IDP to the mapping rule. But I think this is going in the wrong
direction for several reasons:

1. With Shibboleth, if you use a WAYF service, then anyone from hundreds
of different federated IDPs may end up being used to authenticate the
user who is accessing OpenStack/Keystone. We dont want to have hundreds
of URLs. One is sufficient. Plus we dont know which IDP the user will
eventually choose, as this is decided by the WAYF service. So the
"correct" URL cannot be pre-chosen by the user.

2. With ABFAB, the IDP to be used is not known by the SP (Keystone)
until after authentication. This is because the realm is incorporated in
the user's ID (user at real.com) and this is not visible to Keystone. So it
is not possible to have different URLs for different IDPs. They all have
to use the same URL.

So there should be one URL protecting Keystone, and when the response
comes from Apache, Keystone needs to be able to reliably determine

a) which IDP was used by the user
b) which protocol was used

and from this, choose which mapping rule to use

regards

david


On 24/12/2014 10:19, Marco Fargetta wrote:
> Hi All,
> 
> this bug was already reported and fixed in two steps:
> 
> https://bugs.launchpad.net/ossn/+bug/1390124
> 
> 
> The first step is in the documentation. There should be also an OSS advice for previous
> version of OpenStack. The solution consist in configuring shibboleth to use different IdPs for 
> different URLs.
> 
> The second step, still in progress, is to include an ID in the IdP configuration. My patch is under review here:
> 
> https://review.openstack.org/#/c/142743/
> 
> Let me know if it is enough to solve the issue in your case.
> 
> Marco
> 
>> On 24 Dec 2014, at 10:08, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>
>>
>>
>> On 23/12/2014 21:56, Morgan Fainberg wrote:
>>>
>>>> On Dec 23, 2014, at 1:08 PM, Dolph Mathews <dolph.mathews at gmail.com
>>>> <mailto:dolph.mathews at gmail.com>> wrote:
>>>>
>>>>
>>>> On Tue, Dec 23, 2014 at 1:33 PM, David
>>>> Chadwick <d.w.chadwick at kent.ac.uk <mailto: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.
>>>
>>> Fixing this “bug” would be moving towards Keystone needing to implement
>>> all of the various protocols to avoid “misconfigurations”. There are
>>> probably some more values that can be passed down from the Apache layer
>>> to help provide more confidence in the IDP that is being used. I don’t
>>> see a real tangible benefit to moving away from leveraging HTTPD for
>>> handling the heavy lifting when handling federated Identity. 
>>
>> Its not as heavy as you suggest. Apache would still do all the protocol
>> negotiation and validation. Keystone would only need to verify the
>> signature of the incoming SAML assertion in order to validate who the
>> IDP was, and that it was SAML. (Remember that Keystone already
>> implements SAML for sending out SAML assertions, which is much more
>> heavyweight.) ABFAB sends an unsigned SAML assertion embedded in a
>> Radius attribute, so obtaining this and doing a minimum of field
>> checking would be sufficient. There will be something similar that can
>> be done for OpenID Connect.
>>
>> So we are not talking about redoing all the protocol handling, simply
>> checking that the trust rules that have already been configured into
>> Keystone, are actually being followed by Apache. "Trust but verify" in
>> the words of Ronald Regan.
>>
>> regards
>>
>> David
>>
>>>
>>> —Morgan
>>>
>>>>
>>>>    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
>>>>    <mailto: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
>>>>    <mailto: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
>>>>    <mailto: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
>>>> <mailto: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
> 
> ====================================================
> Eng. Marco Fargetta, PhD
> 
> Istituto Nazionale di Fisica Nucleare (INFN)
> Catania, Italy
> 
> EMail: Marco.Fargetta at ct.infn.it
> ====================================================
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>