<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 11, 2013 at 10:25 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David Chadwick wrote up an in depth API extension for Federation: <a href="https://review.openstack.org/#/c/39499" target="_blank">https://review.openstack.org/#<u></u>/c/39499</a><br>

There is an abfab API proposal as well: <a href="https://review.openstack.org/#/c/42221/" target="_blank">https://review.openstack.org/#<u></u>/c/42221/</a><br>
<br>
After discussing this for a while, it dawned on me that Federation should not be something bolted on to Keystone, but rather that it was already central to the design.<br>
<br>
The SQL Identity backend is a simple password store that collects users into groups.  This makes it an identity provider (IdP).<br>
Now Keystone can register multiple LDAP servers as Identity backends.<br>
<br>
There are requests for SAML and ABFAB integration into Keystone as well.<br>
<br>
Instead of a "Federation API"  Keystone should take the key concepts from the API and make them core concepts.  What would this mean:<br>
<br>
1.  Instead of "method": "federation" "protocol": "abfab"  it would be "method": "abfab",<br>
2.  The rules about multiple round trips (phase)  would go under the "abfab" section.<br>
3.  There would not be a "protocol_data" section but rather that would be the "abfab" section as well.<br>
4.  Provider ID would be standard in the method specific section.<br></blockquote><div><br></div><div>That sounds like it fits with the original intention of the "method" portion of the auth API.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One question that has come up has been about Providers, and whether they should be considered endpoints in the Catalog.  THere is a couple issues wiuth this:  one is that they are not something managed by OpenStack, and two is that they are not necessarily Web Protocols.</blockquote>
<div><br></div><div>What's the use case for including providers in the service catalog? i.e. why do Identity API clients need to be aware of the Identity Providers?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As such, Provider should probably be First class citizen.  We already have LDAP  handled this way, although not as an enumerated entity.</blockquote><div><br></div><div>Can you be more specific? What does it mean to be a first class citizen in this context? The fact that identity is backed by LDAP today is abstracted away from Identity API clients, for example.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the first iteration, I would like to see ABFAB, SAML, and any other protocols we support done the same way as LDAP:  a deliberate configuration option for Keystone that will require a config file change.<br>

<br>
David and I have discussed this in a side conversation, and agree that it requires wider input.<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>