Open Stack

On 09/11/2013 02:05 PM, Dolph Mathews wrote:
>
> On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick 
> <d.w.chadwick at kent.ac.uk <mailto: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/
>
>     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/

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.

>
>     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
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
>
> -Dolph
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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