<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/11/2013 12:35 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gW8tMuxQsXLwVWpweBF33Ard4OJDVSmMArpaF_x9=S8XA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/39499"
target="_blank">https://review.openstack.org/#/c/39499</a><br>
There is an abfab API proposal as well: <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/42221/"
target="_blank">https://review.openstack.org/#/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>
</div>
</div>
</blockquote>
In the federation protocol API, the user can specify the IdP that
they are using. Keystone needs to know what are the set of
acceptable IdPs, somehow. The first thought was reuse of the
Service catalog.<br>
It probably makes sense to let an administrator enumerate the IdPs
registered with Keystone, and what protocol each supports.<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gW8tMuxQsXLwVWpweBF33Ard4OJDVSmMArpaF_x9=S8XA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><br>
</div>
-Dolph
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>