Open Stack

On 09/11/2013 12:35 PM, Dolph Mathews wrote:
>
> On Wed, Sep 11, 2013 at 10:25 AM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     David Chadwick wrote up an in depth API extension for Federation:
>     https://review.openstack.org/#/c/39499
>     There is an abfab API proposal as well:
>     https://review.openstack.org/#/c/42221/
>
>     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.
>
>     The SQL Identity backend is a simple password store that collects
>     users into groups.  This makes it an identity provider (IdP).
>     Now Keystone can register multiple LDAP servers as Identity backends.
>
>     There are requests for SAML and ABFAB integration into Keystone as
>     well.
>
>     Instead of a "Federation API"  Keystone should take the key
>     concepts from the API and make them core concepts.  What would
>     this mean:
>
>     1.  Instead of "method": "federation" "protocol": "abfab"  it
>     would be "method": "abfab",
>     2.  The rules about multiple round trips (phase)  would go under
>     the "abfab" section.
>     3.  There would not be a "protocol_data" section but rather that
>     would be the "abfab" section as well.
>     4.  Provider ID would be standard in the method specific section.
>
>
> That sounds like it fits with the original intention of the "method" 
> portion of the auth API.
>
>
>     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.
>
>
> 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?
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.
It probably makes sense to let an administrator enumerate the IdPs 
registered with Keystone, and what protocol each supports.


>
>     As such, Provider should probably be First class citizen.  We
>     already have LDAP  handled this way, although not as an enumerated
>     entity.
>
>
> 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.
>
>     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.
>
>     David and I have discussed this in a side conversation, and agree
>     that it requires wider input.
>
>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
>
> -Dolph
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/36d84934/attachment.html>