<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><snip></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Would you please shed some light on how to configure Keystone for OAuth1? Thank you very much.</div></div></blockquote><div><br></div><div>There is some documentation in the API but nothing formally written out: <a href="http://developer.openstack.org/api-ref/identity/v3-ext/index.html">http://developer.openstack.org/api-ref/identity/v3-ext/index.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I am trying to develop OAuth 2 client for Keystone. We will contribute our OAuth 2 client source code to the community if we can use Google/Facebook to log in to OpenStack through OAuth 2 client.</div><div><br></div></div></blockquote><div><br></div><div>Currently you can setup keystone to work with Google / Facebook and other social logins. If you've setup keystone to use Shibboleth (which you did, I snipped that part of the message), then you can set it up to use these social logins as well. See documentation here: <a href="http://docs.openstack.org/developer/keystone/federation/federated_identity.html#id4">http://docs.openstack.org/developer/keystone/federation/federated_identity.html#id4</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Thanks.</div><div><br></div><div>Best regards,</div><div><br></div><div>Winston Hong</div><div>Ottawa, Ontario</div><div>Canada</div><div><br></div><div><br></div><div>Steve Martinelli <s.martinelli [at] gmail> Jun 27, 2016, 10:57 PM </div><div><br></div><div>> So, the os-oauth routes you mention in the documentation do not make </div><div>> keystone a proper oauth provider. We simply perform delegation (one user </div><div>> handing some level of permission on a project to another entity) with the </div><div>> standard flow established in the oauth1.0b specification. </div><div>> </div><div>> Historically we chose oauth1.0 because one of the implementers was very </div><div>> much against a flow based on oauth2.0 (though the names are similar, these </div><div>> can be treated as two very different beasts, you can read about it here </div><div>> [1]). Even amongst popular service providers the choice is split down the </div><div>> middle, some providing support for both [2] </div><div>> </div><div>> We haven't bothered to implement support for oauth2.0 since there has been </div><div>> no feedback or desire from operators to do so. Mostly, we don't want </div><div>> yet-another-delegation mechanism in keystone, we have trusts and oauth1.0; </div><div>> should an enticing use case arise to include another, then we can revisit </div><div>> the discussion. </div><div>> </div><div>> [1] <a href="https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/" target="_blank">https://hueniverse.com/2012/<wbr>07/26/oauth-2-0-and-the-road-<wbr>to-hell/</a> </div><div>> [2] <a href="https://en.wikipedia.org/wiki/List_of_OAuth_providers" target="_blank">https://en.wikipedia.org/wiki/<wbr>List_of_OAuth_providers</a></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>