[openstack-dev] [keystone] "SAML consumption" Blueprints

Dolph Mathews dolph.mathews at gmail.com
Fri Feb 21 02:05:47 UTC 2014


On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta
<Marco.Fargetta at ct.infn.it>wrote:

> Dear all,
>
> I am interested to the integration of SAML with keystone and I am analysing
> the following blueprint and its implementation:
>
> https://blueprints.launchpad.net/keystone/+spec/saml-id
>
> https://review.openstack.org/#/c/71353/
>
>
> Looking at the code there is something I cannot undertand. In the code it
> seems you
> will use apache httpd with mod_shib (or other alternatives) to parse saml
> assertion
> and the code inside keystone will read only the values extrapolated by the
> front-end server.
>

That's correct (for icehouse development, at least).


>
> If this is the case, it is not clear to me why you need to register the
> IdPs, with its certificate,
> in keystone using the new federation API. You can filter the IdP in the
> server so why do you need this extra list?
> What is the use of the IdP list and the certificate?
>

This reflects our original design, and it has evolved a bit from the
original design to be a bit more simplified. With the additional dependency
on mod_shib / mod_mellon, we are no longer implementing the certificates
API, but we do still need the IdP API. The IdP API specifically allows us
to track the source of an identity, and apply the correct authorization
mapping (producing the project- and domain-based role assignments that
OpenStack is accostomed to to) to the federated attributes coming from
mod_shib / mod_mellon. The benefit is that federated identities from one
source can have a different level of authorization than those identities
from a different source, even if they (theoretically) had the exact same
SAML assertions.


>
> Is still this implementation open to discussion or the design is frozen
> for the icehouse release?
>

It is certainly still open to discussion (and the implementation open to
review!), but we're past feature proposal freeze; anything that would
require new development (beyond what is already in review) will have to
wait a few weeks for Juno.


>
> Thanks in advance,
> Marco
>
> _______________________________________________
> 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/20140220/1b5f04f6/attachment.html>


More information about the OpenStack-dev mailing list