<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:05 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gUiYkyZgsTykGzzve1p2Wk8QmTsdRVhG+FV3qL=sUWpiA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Sep 11, 2013 at 12:31 PM,
David Chadwick <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Further
supplementary information to Adam's email below, is that
there are already one further federation protocol profiles
that has been published:<br>
for an external Keystone acting as an IdP at<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/42107/"
target="_blank">https://review.openstack.org/#/c/42107/</a><br>
<br>
and another for SAML has been prepared and is ready for
publication.<br>
<br>
I would expect several additional federation profiles to
be published in the future, for example, for OpenID
Connect and what ever else might be just around the
corner.<br>
<br>
Given the fact that the number of federation protocols is
not fixed, and will evolve with time, then I would prefer
their method of integration into Keystone to be common, so
that one "federation" module can handle all the
non-protocol specific federation features, such as policy
and trust checking, and this module can have multiple
different protocol handling modules plugged into it that
deal with the protocol specific features only. This is the
method we have adopted in our current implementation of
federation, and have shown that it is a viable and
efficient way of implementation as we currently support
three protocol profiles (SAML, ABFAB and External
Keystone).<br>
<br>
Thus I prefer<br>
<br>
"method": "federation" "protocol": "abfab"<br>
<br>
in which the abfab part would be replaced by the
particular protocol, and there are common parameters to be
used by the federation module </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
instead of "method": "abfab"<br>
<br>
as the latter removes the common parameters from
federation, and also means that common code wont be used,
unless it is cut and paste into each protocol specific
module.<br>
</blockquote>
<div><br>
</div>
<div>That sounds like a pretty strong argument in favor of
the current design, assuming the "abfab" parameters are
children of the common "federation" parameters (rather
than a sibling of the "federation" parameters)... which
does appear to be the case the current patchset- <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/42221/"
target="_blank">https://review.openstack.org/#/c/42221/</a><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
And this is where David and I disagree. I don't think Federation is
"in addition to Keystone" but rather it is fundamental to Keystone.
I don't think "method" :" federation" is a necessary abstraction.
I think what David is trying to acheive is best done as a set of
standards on how to add any provider: we don't need a wrapper
around a wrapper.<br>
<br>
<blockquote
cite="mid:CAC=h7gUiYkyZgsTykGzzve1p2Wk8QmTsdRVhG+FV3qL=sUWpiA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Comments?<span class=""><font color="#888888"><br>
<br>
David</font></span>
<div class="">
<div class="h5"><br>
<br>
<br>
On 11/09/2013 16:25, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">David
Chadwick wrote up an in depth API extension for
Federation:<br>
<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:<br>
<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<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 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>
<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>
</div>
</div>
</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>