Open Stack

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/

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.

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
> 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