Open Stack

On 12/09/2013 16:55, Dolph Mathews wrote:
>
> On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick <d.w.chadwick at kent.ac.uk
> <mailto: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

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 at lists.openstack.__org
>     <mailto: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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>