Sorry - lost some links :) Unified delegation spec: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-delegation.html About OAuth2: https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
On Wed, Sep 14, 2016 at 10:58 AM, Alexander Makarov <[email protected]> wrote: > Actually OAuth support is my next step in "unified delegations" effort > [0], so it's a good time to think about what version of it should be > supported. > > Along with that I have some concerns about OAuth v2, as IIRC authors > themselves abandoned the spec. I'll check if something changed since that > time. > > On 13.09.2016 00:43, Steve Martinelli wrote: > > <snip> > >> >> Would you please shed some light on how to configure Keystone for OAuth1? >> Thank you very much. >> > > There is some documentation in the API but nothing formally written out: > http://developer.openstack.org/api-ref/identity/v3-ext/index.html > > >> >> 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. >> >> > 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: http://docs.openstack. > org/developer/keystone/federation/federated_identity.html#id4 > > >> 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:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
