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