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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
