Open Stack

On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick <d.w.chadwick at kent.ac.uk>wrote:

> Further supplementary information to Adam's email below, is that there are
> already one further federation protocol profiles that has been published:
> for an external Keystone acting as an IdP at
> https://review.openstack.org/#**/c/42107/<https://review.openstack.org/#/c/42107/>
>
> and another for SAML has been prepared and is ready for publication.
>
> 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.
>
> 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).
>
> Thus I prefer
>
> "method": "federation" "protocol": "abfab"
>
> in which the abfab part would be replaced by the particular protocol, and
> there are common parameters to be used by the federation module


> instead of "method": "abfab"
>
> 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.
>

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-
https://review.openstack.org/#**/c/42221/<https://review.openstack.org/#/c/42221/>


>
> Comments?
>
> David
>
>
>
> On 11/09/2013 16:25, Adam Young wrote:
>
>> David Chadwick wrote up an in depth API extension for Federation:
>> https://review.openstack.org/#**/c/39499<https://review.openstack.org/#/c/39499>
>> There is an abfab API proposal as well:
>> https://review.openstack.org/#**/c/42221/<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 <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 

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