Open Stack

Hello Steve.

Thank you very much for your great work on OAuth 1 authentication for
Keystone.

(1) I have configured Keystone for Federation by following the instructions
below.

Then I can log in to OpenStack through Shibboleth identity provider.


Configuring Keystone for Federation
http://docs.openstack.org/developer/keystone/mitaka/configure_federation.html

-----------------------------------------------------------------------------------------

(2) I can NOT find the instructions on Configuring Keystone for OAuth1.

I also can NOT find the instructions on Configuring Keystone for OAuth2.

http://docs.openstack.org/developer/keystone/mitaka/

Instead I only find the developers' documentation on OAuth2 for OpenStack
(OpenStack/Keystone?)

http://docs.openstack.org/infra/openstackid/oauth2.html

OAuth2 IdP?

https://github.com/openstack-infra/openstackid

Comparing the source code keystone-8.0.0.0b1.tar.gz with the GitHub
repository, I discover that there has been fundemental update on oAuth 1
module.

(2a) For keystone-8.0.0.0b1.tar.gz

https://github.com/openstack/keystone/releases?after=9.0.0.0b1

keystone/contrib/oauth1

backends/ controllers.py core.py routers.py validator.py

(2b) For the GitHub repository,

https://github.com/openstack/keystone/tree/master/keystone

keystone/contrib/oauth1

backends/ routers.py

keystone/oauth1

controllers.py core.py routers.py schema.py validator.py

-----------------------------------------------------------------------------------------

Would you please shed some light on how to configure Keystone for OAuth1?
Thank you very much.

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.

Thanks.

Best regards,

Winston Hong
Ottawa, Ontario
Canada


Steve Martinelli <s.martinelli [at] gmail> Jun 27, 2016, 10:57 PM

> So, the os-oauth routes you mention in the documentation do not make
> keystone a proper oauth provider. We simply perform delegation (one user
> handing some level of permission on a project to another entity) with the
> standard flow established in the oauth1.0b specification.
>
> Historically we chose oauth1.0 because one of the implementers was very
> much against a flow based on oauth2.0 (though the names are similar,
these
> can be treated as two very different beasts, you can read about it here
> [1]). Even amongst popular service providers the choice is split down the
> middle, some providing support for both [2]
>
> We haven't bothered to implement support for oauth2.0 since there has
been
> no feedback or desire from operators to do so. Mostly, we don't want
> yet-another-delegation mechanism in keystone, we have trusts and
oauth1.0;
> should an enticing use case arise to include another, then we can revisit
> the discussion.
>
> [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
> [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160912/17ec6a14/attachment.html>