<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
On 11/09/2013 22:05, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
What's the use case for including providers in the service catalog?<br>
i.e. why do Identity API clients need to be aware of the Identity<br>
Providers?<br>
</blockquote>
In the federation protocol API, the user can specify the IdP that they<br>
are using. Keystone needs to know what are the set of acceptable IdPs,<br>
somehow.  The first thought was reuse of the Service catalog.<br>
It probably makes sense to let an administrator enumerate the IdPs<br>
registered with Keystone, and what protocol each supports.<br>
</blockquote>
<br></div>
There are several reasons why Keystone needs to be aware of which IDPs are out there.<br>
1. Trust. Keystone administrators will only trust a subset of available IDPs, and this information needs to be configured into Keystone in some way<br>
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<br>
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.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>  <a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#authentication-failures">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#authentication-failures</a></div>
<div><br></div><div>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<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
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<br>

<br>
regards<span class=""><font color="#888888"><br>
<br>
David</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>