On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick <[email protected]>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 > [email protected].**org <[email protected]> > 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
