On 12/09/2013 16:55, Dolph Mathews wrote:
On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick <d.w.chadw...@kent.ac.uk
<mailto:d.w.chadw...@kent.ac.uk>> wrote:
On 11/09/2013 22:05, Adam Young wrote:
What's the use case for including providers in the service
catalog?
i.e. why do Identity API clients need to be aware of the
Identity
Providers?
In the federation protocol API, the user can specify the IdP
that they
are using. Keystone needs to know what are the set of acceptable
IdPs,
somehow. The first thought was reuse of the Service catalog.
It probably makes sense to let an administrator enumerate the IdPs
registered with Keystone, and what protocol each supports.
There are several reasons why Keystone needs to be aware of which
IDPs are out there.
1. Trust. Keystone administrators will only trust a subset of
available IDPs, and this information needs to be configured into
Keystone in some way
2. Discovery. Keystone needs to be able to discover details of which
IDPs are trusted and how to contact them (meta data). This needs to
be configured into Keystone somehow
3. Helping the user. The user might needs to know which IdPs it can
use and which it cannot, so Keystone may need to provide the user
with a list of IdPs to choose from.
Of all these use cases, only the last one actually involves API clients,
and it's a "might." Even then, it doesn't feel like an obvious use case
for the service catalog. The Identity API doesn't currently have a great
way to advertise support authentication methods (401 response lists
them, but you can't just GET that list).
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#authentication-failures
I suspect these two challenges are related and should be solved
together? i.e. GET /auth/methods -> returns a dict of auth methods
containing metadata about each
Yes correct. This was step 1 of our original 5 phase federation proposal
(which got reduced to 3 as the first 2 steps are actually independent of
federation). See
https://review.openstack.org/#/c/39499/3/openstack-identity-api/v3/src/markdown/identity-api-v3-federation-ext.md,unified
So we should define this method and make it independent of federation.
Whether we need two phases (find out supported methods and protocols
followed by get details of IDPs, or one combined method that does both
is a detailed design issue)
regards
David
Using the service catalog to hold the above information was a
pragmatic implementation decision that Kent made. What is
conceptually needed is a directory service that Keystone can contact
to find out the required information. So we should design federated
keystone to have a directory service interface, and then
implementors may choose to use the service catalog or something else
to fulfil this function
regards
David
_________________________________________________
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
