Open Stack

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/
>     <https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/>
>     > [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
>     <https://en.wikipedia.org/wiki/List_of_OAuth_providers>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/3488bbd3/attachment.html>