Re: [openstack-dev] [Keystone] Bug in federation

[Marco Fargetta]

Hi David,

in principle I agree with your comments. The current design mixes
different aspect up and it is not manageable when the number of IdPs
get bigger, like in the case you should allow access from users in a
country federation, especially compared to other tools supporting
identity federation.

Nevertheless, I think you have to consider the current implementation
like a fusion between the discovery protocol and the
authentication. Users, instead of being re-directed to a Discovery
Service providing the list of IdPs, receive the list from keystone
itself. Each endpoint URL is an IdP the user can use to authenticate
and when selected the user should go directly to the IdP and not into
the DS. Of course I am not saying this is good but it is acceptable
from the user point of view. There is not the problem to map IdPs in
the DS with endpoint URL because it is made in advance.

By the way, if you change the approach and create a single URL for the
authentication then I cannot see the use of a list of trusted
IdPs. You should disable the not accepted IdPs at higher level so to
avoid the situation where a user authenticate into the IdP but cannot
access the service. You may work at apache and DS level to enable only
trusted IdPs. Then you need a better mapping in order to put your
logic there.

I think this is a significant change and if there is agreement I think
it is possible to end with a more flexible design.

Do you plan to propose a new spec?

Marco







On Fri, Jan 02, 2015 at 09:51:55PM +, David Chadwick wrote:
 Hi Marco
 
 I think the current design is wrong because it is mixing up access
 control with service endpoint location. The endpoint of a service should
 be independent of the access control rules determining who can contact
 the service. Any entity should be able to contact a service endpoint
 (subject to firewall rules of course, but this is out of scope of
 Keystone), and once connected, access control should then be enforced.
 Unfortunately the current design directly ties access control (which
 IdP) to the service endpoint by building the IDP name into the URL. This
 is fundamentally a bad design. Not only is it too limiting, but also it
 is mixing up different concerns, rather than separating them out, which
 is a good computer science principle.
 
 So, applying the separation of concerns principle to Keystone, the
 federated login endpoint should not be tied to any specific IdP. There
 are many practical reasons for this, such as:
 
 a) in the general case the users of an openstack service could be from
 multiple different organisations, and hence multiple different IdPs, but
 they may all need to access the same service and hence same endpoint,
 b) users who are authorised to access an openstack service might be
 authorised based on their identity attributes that are not IdP specific
 (e.g. email address), so they might have a choice of IDP to use
 c) federations are getting larger and larger, and interfederations are
 exploding the number of IdPs that users can use. The GEANT eduGAIN
 interfederation for example now has IdPs from about 20 countries, and
 each country can have over a 100 IdPs. So we are talking about thousands
 of IdPs in a federation. It is conceivable that users from all of these
 might wish to access a given cloud service.
 
 Here is my proposal for how federation should be re-engineered
 
 1. The federation endpoint URL for Keystone can be anything intuitive
 and in keeping with existing guidelines, and should be IDP independent
 
 2. Apache will protect this endpoint with whatever federation
 protocol(s) it is able to. The Keystone administrator and Apache
 administrator will liaise out of band to determine the name of the
 endpoint and the federation protocol and IDPs that will be able to
 access it.
 
 3. Keystone will have its list of trusted IdPs as now.
 
 4. Keystone will have its mapping rules as now (although I still believe
 it would be better for mapping rules to be IDP independent, and to have
 lists of trusted attributes from trusted IDPs instead)
 
 5. Apache will return to Keystone two new parameters indicating the IdP
 and protocol that were used by the user in connecting to the endpoint.
 Apache knows what these are.
 
 6. Keystone will use these new parameters for access control and mapping
 rules. i.e. it will reject any users who are from untrusted IdPs, and it
 will determine the right mapping rule to use based on the values of the
 two new parameters. A simple table in Keystone will map the IdPs and
 protocols into the correct mapping rule to use.
 
 This is not a huge change to make, in fact it should be a rather simple
 re-engineering task.
 
 regards
 
 David
 
 
 On 24/12/2014 17:50, Marco Fargetta wrote:
  
  On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote:
 
  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
  

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

Hi Marco

1. I agree that a discovery service is needed somewhere in the
federation architecture. But the discovery service should be independent
of the endpoint URL that is used to access OpenStack services via
Keystone. It is not a good design to mix up these two aspects, which
appears to have been done in the current design. So Keystone could still
offer a discovery service to end users, by returning details of the IDPs
that it trusts, and information about how to contact those IdPs. But all
the federated users should still be redirected back to the same endpoint
URL of Keystone. Then if discovery is offered by something other than
Keystone, Keystone can still validate federated user authentication.

2. Discovery is different from trust management. The discovery service
could be separate from Keystone (and Apache), but Keystone (or Apache)
would still need a way of specifying which IdPs are trusted, so as to
reject users authenticated by untrusted IdPs.

3. In ABFAB, discovery is part of the ABFAB protocol suite, since
usernames contain the domain name of the user (e.g. d.c...@kent.ac.uk)
which allows Radius to route the user to the correct IDP. Hence ABFAB
does not require Keystone to be the discovery service. But Keystone (or
Apache) still needs to perform trust management to reject users from
untrusted IdPs.

More comments below about the current design, which is clearly sub-optimal.


On 05/01/2015 10:33, Marco Fargetta wrote:
 Hi David,
 
 in principle I agree with your comments. The current design mixes
 different aspect up and it is not manageable when the number of IdPs
 get bigger, like in the case you should allow access from users in a
 country federation, especially compared to other tools supporting
 identity federation.
 
 Nevertheless, I think you have to consider the current implementation
 like a fusion between the discovery protocol and the
 authentication.

this is still mixing up aspects!

 Users, instead of being re-directed to a Discovery
 Service providing the list of IdPs, receive the list from keystone
 itself. 

The list of IdPs and the endpoint URL are two different concepts and
should not be mixed up together (which they currently are). You should
be able to tell the user the list of IdPs to choose from, and still have
a single endpoint URL. You could in our original federation
implementation :-)


 Each endpoint URL is an IdP the user can use to authenticate

Sorry it is not quite that. The endpoint is not an IDP, but rather it is
the endpoint that the user has to return to after being authenticated by
the IDP.

 and when selected the user should go directly to the IdP

the discovery service should tell the user how to get to this IDP, but
not where in Keystone to return to, since in general, the Disco service
should be usable by multiple service providers. Therefore the
information it provides should be independent of the service providers
(which in the current implementation it is not).

 and not into
 the DS. Of course I am not saying this is good but it is acceptable
 from the user point of view. There is not the problem to map IdPs in
 the DS with endpoint URL because it is made in advance.

This mapping is not needed in my opinion.

 
 By the way, if you change the approach and create a single URL for the
 authentication then I cannot see the use of a list of trusted
 IdPs.

as stated above trust management is separate from and different to
discovery. Dont confuse the two.

 You should disable the not accepted IdPs at higher level so to
 avoid the situation where a user authenticate into the IdP but cannot
 access the service.

In general you can never prevent this, since the endpoint is public
information (which is usually published).

 You may work at apache and DS level to enable only
 trusted IdPs. Then you need a better mapping in order to put your
 logic there.
 
 I think this is a significant change and if there is agreement I think
 it is possible to end with a more flexible design.

this is needed in my opinion.

 
 Do you plan to propose a new spec?

Not at the current time. There is little point in producing designs that
no-one is willing to implement :-) Once the core implementers accept
that the current design is poor and needs re-engineering, then I will be
happy to propose a new design

regards

David

 
 Marco
 
 
 
 
 
 
 
 On Fri, Jan 02, 2015 at 09:51:55PM +, David Chadwick wrote:
 Hi Marco

 I think the current design is wrong because it is mixing up access
 control with service endpoint location. The endpoint of a service should
 be independent of the access control rules determining who can contact
 the service. Any entity should be able to contact a service endpoint
 (subject to firewall rules of course, but this is out of scope of
 Keystone), and once connected, access control should then be enforced.
 Unfortunately the current design directly ties access control (which
 IdP) to the service endpoint by building the IDP name into the URL. 

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

Hi Marco

I think the current design is wrong because it is mixing up access
control with service endpoint location. The endpoint of a service should
be independent of the access control rules determining who can contact
the service. Any entity should be able to contact a service endpoint
(subject to firewall rules of course, but this is out of scope of
Keystone), and once connected, access control should then be enforced.
Unfortunately the current design directly ties access control (which
IdP) to the service endpoint by building the IDP name into the URL. This
is fundamentally a bad design. Not only is it too limiting, but also it
is mixing up different concerns, rather than separating them out, which
is a good computer science principle.

So, applying the separation of concerns principle to Keystone, the
federated login endpoint should not be tied to any specific IdP. There
are many practical reasons for this, such as:

a) in the general case the users of an openstack service could be from
multiple different organisations, and hence multiple different IdPs, but
they may all need to access the same service and hence same endpoint,
b) users who are authorised to access an openstack service might be
authorised based on their identity attributes that are not IdP specific
(e.g. email address), so they might have a choice of IDP to use
c) federations are getting larger and larger, and interfederations are
exploding the number of IdPs that users can use. The GEANT eduGAIN
interfederation for example now has IdPs from about 20 countries, and
each country can have over a 100 IdPs. So we are talking about thousands
of IdPs in a federation. It is conceivable that users from all of these
might wish to access a given cloud service.

Here is my proposal for how federation should be re-engineered

1. The federation endpoint URL for Keystone can be anything intuitive
and in keeping with existing guidelines, and should be IDP independent

2. Apache will protect this endpoint with whatever federation
protocol(s) it is able to. The Keystone administrator and Apache
administrator will liaise out of band to determine the name of the
endpoint and the federation protocol and IDPs that will be able to
access it.

3. Keystone will have its list of trusted IdPs as now.

4. Keystone will have its mapping rules as now (although I still believe
it would be better for mapping rules to be IDP independent, and to have
lists of trusted attributes from trusted IDPs instead)

5. Apache will return to Keystone two new parameters indicating the IdP
and protocol that were used by the user in connecting to the endpoint.
Apache knows what these are.

6. Keystone will use these new parameters for access control and mapping
rules. i.e. it will reject any users who are from untrusted IdPs, and it
will determine the right mapping rule to use based on the values of the
two new parameters. A simple table in Keystone will map the IdPs and
protocols into the correct mapping rule to use.

This is not a huge change to make, in fact it should be a rather simple
re-engineering task.

regards

David


On 24/12/2014 17:50, Marco Fargetta wrote:
 
 On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote:

 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.

 
 
 With the proposed configuration of shibboleth when you access the URL then 
 you are
 redirect only to the IdP configured for the URL. Since a URL is tied to only 
 an IDP there
 is not need of a WAYF.
 
 Anyway, this is a change only in the documentation and it was the first fix 
 because there was
 an agreement to provide a solution also for Juno with the minimal change in 
 the code.
 
 The other fix I proposed, which is under review, requires an additional 
 parameter when you
 configure the IdP in OS-Federation. This accepts one or more EntityIDs so you 
 can map the entities
 with the URL. This also requires to specify the http variable where you can 
 get the entityID (this
 is a parameter so it can be compatible with different SAML plug-ins).
 If you do not specify these values the behaviour is like the current 
 implementation otherwise
 providing the list of entities and the parameter the access to the URL is 
 allowed only to the
 IDP included in the list and the other are rejected.
 
 I tried to be more compatible with the current implementation as possible.
 
 Is this in the right direction? Could you comment on the review page? It will 
 be better to 

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

On 23/12/2014 21:56, Morgan Fainberg wrote:
 
 On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
 mailto:dolph.math...@gmail.com wrote:


 On Tue, Dec 23, 2014 at 1:33 PM, David
 Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@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 :
 
 
  
 

Re: [openstack-dev] [Keystone] Bug in federation

[Marco Fargetta]

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.chadw...@kent.ac.uk wrote:
 
 
 
 On 23/12/2014 21:56, Morgan Fainberg wrote:
 
 On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
 mailto:dolph.math...@gmail.com wrote:
 
 
 On Tue, Dec 23, 2014 at 1:33 PM, David
 Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@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 

Re: [openstack-dev] [Keystone] Bug in federation

[John Dennis]

Can't this be solved with a couple of environment variables? The two
keys pieces of information needed are:

1) who authenticated the subject?

2) what authentication method was used?

There is already precedence for AUTH_TYPE, it's used in AJP to
initialize the authType property in a Java Servelet. AUTH_TYPE would
cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps
there could be a convention that AUTH_TYPE could carry extra qualifying
parameters much like HTTP headers do. The first token would be the
primary mechanism, e.g. saml, negotiate, x509, etc. For authentication
types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra
parameter would qualify the actual mechanism used. For SAML that
qualifying extra parameter could be the value from AuthnContextClassRef.

Item 1 could be covered by a new environment variable AUTH_AUTHORITY.

If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would
be the KDC. For SAML it would probably be taken from the
AuthenticatingAuthority element or the IdP entityID.

I'm not sure I see the need for other layers to receive the full SAML
assertion and validate the signature. One has to trust the server you're
running in. It's the same concept as trusting REMOTE_USER.

-- 
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

HI John

On 24/12/2014 14:15, John Dennis wrote:
 Can't this be solved with a couple of environment variables? The two
 keys pieces of information needed are:
 
 1) who authenticated the subject?

AUTH_AUTHORITY or similar would stop wrong configuration of Apache if it
was set by the protocol plugin module from the protocol messages it
received. But it may take time for all plugin suppliers to adopt this
and implement it.

 
 2) what authentication method was used?

Its not the authentication method that is being questioned (could be
un/pw, two factor or any other method), but rather the federation
protocol that was used. So I dont think AUTH-TYPE is the right parameter
for what is required.

 
 There is already precedence for AUTH_TYPE, it's used in AJP to
 initialize the authType property in a Java Servelet. AUTH_TYPE would
 cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps
 there could be a convention that AUTH_TYPE could carry extra qualifying
 parameters much like HTTP headers do. The first token would be the
 primary mechanism, e.g. saml, negotiate, x509, etc. For authentication
 types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra
 parameter would qualify the actual mechanism used. For SAML that
 qualifying extra parameter could be the value from AuthnContextClassRef.
 
 Item 1 could be covered by a new environment variable AUTH_AUTHORITY.
 
 If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would
 be the KDC. For SAML it would probably be taken from the
 AuthenticatingAuthority element or the IdP entityID.
 
 I'm not sure I see the need for other layers to receive the full SAML
 assertion and validate the signature. One has to trust the server you're
 running in. It's the same concept as trusting REMOTE_USER.
 

Not quite. A badly configured Apache would not (should not) effect
REMOTE_USER as this should be set by the authn plugin. Currently we have
nothing to check that Apache was correctly configured

regards

David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

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 (u...@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.chadw...@kent.ac.uk wrote:



 On 23/12/2014 21:56, Morgan Fainberg wrote:

 On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
 mailto:dolph.math...@gmail.com wrote:


 On Tue, Dec 23, 2014 at 1:33 PM, David
 Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@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, 

Re: [openstack-dev] [Keystone] Bug in federation

[Marco Fargetta]

 On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote:
 
 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.
 


With the proposed configuration of shibboleth when you access the URL then you 
are
redirect only to the IdP configured for the URL. Since a URL is tied to only an 
IDP there
is not need of a WAYF.

Anyway, this is a change only in the documentation and it was the first fix 
because there was
an agreement to provide a solution also for Juno with the minimal change in the 
code.

The other fix I proposed, which is under review, requires an additional 
parameter when you
configure the IdP in OS-Federation. This accepts one or more EntityIDs so you 
can map the entities
with the URL. This also requires to specify the http variable where you can get 
the entityID (this
is a parameter so it can be compatible with different SAML plug-ins).
If you do not specify these values the behaviour is like the current 
implementation otherwise
providing the list of entities and the parameter the access to the URL is 
allowed only to the
IDP included in the list and the other are rejected.

I tried to be more compatible with the current implementation as possible.

Is this in the right direction? Could you comment on the review page? It will 
be better to understand
it the patch need extra work. The link is: 
https://review.openstack.org/#/c/142743/

 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 (u...@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
 


This would require a new design of the OS-Federation and you have proposed 
several specs
I was agreeing with. Nevertheless, it seems there was not consensus in the 
community so
I think you have to find a way to integrate ABFAB with the current model.

Is it possible to have a single mapping with many rules and keystone chose 
according to the
information coming after the authentication? Maybe this require to work on the 
mapping but it does not
require changes in the overall architecture, just an idea.




 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.chadw...@kent.ac.uk wrote:
 
 
 
 On 23/12/2014 21:56, Morgan Fainberg wrote:
 
 On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
 mailto:dolph.math...@gmail.com wrote:
 
 
 On Tue, Dec 23, 2014 at 1:33 PM, David
 Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@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 

Re: [openstack-dev] [Keystone] Bug in federation

[Marco Fargetta]

Hi John,
the problem is not to establish which variable has the correct information but 
the association
between IDP and URL. In OS-Federation you define an authentication URL per IDP 
and protocol
and it is supposed to use the specified IDP and protocol for authenticate. 
Nevertheless, during the
authentication there is not code to check if the IDP and protocol are the one 
specified for the URL
and in the apache configuration for Juno there was no configuration in the 
apache side to bind the
IDP with the URL.

Therefore, you need to add something in OS_Federation to perform this control 
using the variable you
are proposing or others.

Marco

 On 24 Dec 2014, at 15:15, John Dennis jden...@redhat.com wrote:
 
 Can't this be solved with a couple of environment variables? The two
 keys pieces of information needed are:
 
 1) who authenticated the subject?
 
 2) what authentication method was used?
 
 There is already precedence for AUTH_TYPE, it's used in AJP to
 initialize the authType property in a Java Servelet. AUTH_TYPE would
 cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps
 there could be a convention that AUTH_TYPE could carry extra qualifying
 parameters much like HTTP headers do. The first token would be the
 primary mechanism, e.g. saml, negotiate, x509, etc. For authentication
 types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra
 parameter would qualify the actual mechanism used. For SAML that
 qualifying extra parameter could be the value from AuthnContextClassRef.
 
 Item 1 could be covered by a new environment variable AUTH_AUTHORITY.
 
 If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would
 be the KDC. For SAML it would probably be taken from the
 AuthenticatingAuthority element or the IdP entityID.
 
 I'm not sure I see the need for other layers to receive the full SAML
 assertion and validate the signature. One has to trust the server you're
 running in. It's the same concept as trusting REMOTE_USER.
 
 -- 
 John
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@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.farge...@ct.infn.it




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Bug in federation

[David Chadwick]

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.

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[Adam Young]

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?


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


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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[David Chadwick]

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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[Dolph Mathews]

On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick d.w.chadw...@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@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Bug in federation

[Morgan Fainberg]

 On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com wrote:
 
 
 On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick d.w.chadw...@kent.ac.uk 
 mailto:d.w.chadw...@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. 

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