<font size=2 face="sans-serif">Hi Adam,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Cindy Willman (919) 268-5296</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Adam Young <ayoung@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">09/11/2013 11:28 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[openstack-dev]
Keystone and Multiple Identity Sources</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>David Chadwick wrote up an in depth API extension
for Federation: <br>
</font></tt><a href=https://review.openstack.org/#/c/39499><tt><font size=2>https://review.openstack.org/#/c/39499</font></tt></a><tt><font size=2><br>
There is an abfab API proposal as well: <br>
</font></tt><a href=https://review.openstack.org/#/c/42221/><tt><font size=2>https://review.openstack.org/#/c/42221/</font></tt></a><tt><font size=2><br>
<br>
After discussing this for a while, it dawned on me that Federation <br>
should not be something bolted on to Keystone, but rather that it was <br>
already central to the design.<br>
<br>
The SQL Identity backend is a simple password store that collects users
<br>
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 <br>
from the API and make them core concepts.  What would this mean:<br>
<br>
1.  Instead of "method": "federation" "protocol":
"abfab"  it would be <br>
"method": "abfab",<br>
2.  The rules about multiple round trips (phase)  would go under
the <br>
"abfab" section.<br>
3.  There would not be a "protocol_data" section but rather
that would <br>
be the "abfab" section as well.<br>
4.  Provider ID would be standard in the method specific section.<br>
<br>
One question that has come up has been about Providers, and whether they
<br>
should be considered endpoints in the Catalog.  THere is a couple
issues <br>
wiuth this:  one is that they are not something managed by OpenStack,
<br>
and two is that they are not necessarily Web Protocols.  As such,
<br>
Provider should probably be First class citizen.  We already have
LDAP  <br>
handled this way, although not as an enumerated entity.  For the first
<br>
iteration, I would like to see ABFAB, SAML, and any other protocols we
<br>
support done the same way as LDAP:  a deliberate configuration option
<br>
for Keystone that will require a config file change.<br>
<br>
David and I have discussed this in a side conversation, and agree that
<br>
it requires wider input.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>