<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta <span dir="ltr"><<a href="mailto:Marco.Fargetta@ct.infn.it" target="_blank">Marco.Fargetta@ct.infn.it</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I am interested to the integration of SAML with keystone and I am analysing<br>
the following blueprint and its implementation:<br>
<br>
<a href="https://blueprints.launchpad.net/keystone/+spec/saml-id" target="_blank">https://blueprints.launchpad.net/keystone/+spec/saml-id</a><br>
<br>
<a href="https://review.openstack.org/#/c/71353/" target="_blank">https://review.openstack.org/#/c/71353/</a><br>
<br>
<br>
Looking at the code there is something I cannot undertand. In the code it seems you<br>
will use apache httpd with mod_shib (or other alternatives) to parse saml assertion<br>
and the code inside keystone will read only the values extrapolated by the front-end server.<br></blockquote><div><br></div><div>That's correct (for icehouse development, at least).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
If this is the case, it is not clear to me why you need to register the IdPs, with its certificate,<br>
in keystone using the new federation API. You can filter the IdP in the server so why do you need this extra list?<br>
What is the use of the IdP list and the certificate?<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is still this implementation open to discussion or the design is frozen for the icehouse release?<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks in advance,<br>
Marco<br>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>