Hi Dolph,
On 21 Feb 2014, at 03:05, Dolph Mathews <[email protected]> wrote: > > On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta <[email protected]> > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
