Open Stack

Hi Dolph,


On 21 Feb 2014, at 03:05, Dolph Mathews <dolph.mathews at gmail.com> wrote:

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

The idea to distinguish the IdPs make sense but for SAML I think it is better to work with the attributes only. If the SAML is the same you may work at mod_shib level to
create attributes containing the value you want so it is easier to create a new attribute in the SP having the authorisation level. In this way you can define authorisation rules
using only assertion instead of mixing assertion with IdP names, with …… . I do not know if you can exploit the same approach with OpenId and/or other authentication framework.

Nevertheless, it seems that I am late for icehouse so I will better analyse what you provide now and think what could be done in Juno.

Cheers,
Marco


> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5598 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140221/5e9706d9/attachment.bin>