On 11/09/2013 19:05, Dolph Mathews wrote:
On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick
<d.w.chadw...@kent.ac.uk <mailto: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/>
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@lists.openstack.__org
<mailto: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
<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
