Open Stack

Hi Adam,

One thing I think we should capture before going deep into design and 
implementation is to understand the federated identity use cases that our 
stakeholders need us to support. I'm hoping we all can start capturing 
these in a federated identity icehouse design summit session.

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Cindy Willman (919) 268-5296



From:   Adam Young <ayoung at redhat.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>
Date:   09/11/2013 11:28 AM
Subject:        [openstack-dev] Keystone and Multiple Identity Sources



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.

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.  As such, 
Provider should probably be First class citizen.  We already have LDAP 
handled this way, although not as an enumerated entity.  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
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/4295291b/attachment.html>