Open Stack

On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick <d.w.chadwick at 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


>
> 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 at lists.openstack.**org <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130912/ea5496fe/attachment.html>