<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 02:35 PM, Brad Topol
wrote:<br>
</div>
<blockquote
cite="mid:OFEE7D4E3E.98BEF8A5-ON85257BE3.0062A4B5-85257BE3.006622E8@us.ibm.com"
type="cite"><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>
</blockquote>
<br>
Stakholders. You keep using that term. I do not think it means what
you think it means.<br>
<br>
In this case, we have a pretty good idea what is meant by Federation
in general, and we know what some of the people interested in Open
Stack want. The more input we can get, the better.<br>
<br>
However, We know that we have requests for ABFAB and SAML
integration, and have had discussions about them at the last Summit,
so this is not new stuff. What we are trying to do is figure out
the commonalities of the various Federation approaches so we have
and easily understand approach to integrating new providers.<br>
<blockquote
cite="mid:OFEE7D4E3E.98BEF8A5-ON85257BE3.0062A4B5-85257BE3.006622E8@us.ibm.com"
type="cite">
<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: <a class="moz-txt-link-abbreviated" href="mailto:btopol@us.ibm.com">btopol@us.ibm.com</a><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
<a class="moz-txt-link-rfc2396E" href="mailto:ayoung@redhat.com"><ayoung@redhat.com></a></font>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">OpenStack Development
Mailing List <a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a></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="noshade">
<br>
<br>
<br>
<tt><font size="2">David Chadwick wrote up an in depth API
extension
for Federation: <br>
</font></tt><a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><a moz-do-not-send="true"
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>
<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>