Open Stack

On 11/09/2013 19:05, 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/
>     <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/>

this would require protocol_data to become a child of the other three 
parameters, which can easily be done. The protocol_data is an array of 
any parameters that the protocol specific code wants to put in there. 
The protocol specific profile document specifies what these are.

regards

David


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