On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick <d.w.chadw...@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@lists.openstack.**org <OpenStack-dev@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@lists.openstack.**org <OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev