Open Stack

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 <amakarov at mirantis.com>
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/7cbe47dd/attachment-0001.html>