Open Stack

https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication

On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov <amakarov at mirantis.com>
wrote:

> We could soften this limitation a little by returning token client tries
> to authenticate with.
> I think we need to discuss it in community.
>
> On Mon, Feb 16, 2015 at 6:47 PM, Steven Hardy <shardy at redhat.com> wrote:
>
>> On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote:
>> >    Yeah, clarification from keystone folks would be really helpful.
>> >    If Nikolaya**s info is correct (I believe it is) then I actually
>> dona**t
>> >    understand why trusts are needed at all, they seem to be useless. My
>> >    assumption is that they can be used only if we send requests
>> directly to
>> >    OpenStack services (w/o using clients) with trust scoped token
>> included in
>> >    headers, that might work although I didna**t checked that yet myself.
>> >    So please help us understand which one of my following assumptions is
>> >    correct?
>> >     1. We dona**t understand what trusts are.
>> >     2. We use them in a wrong way. (If yes, then whata**s the correct
>> usage?)
>>
>> One or both of these seems likely, possibly combined with bugs in the
>> clients where they try to get a new token instead of using the one you
>> provide (this is a common pattern in the shell case, as the token is
>> re-requested to get a service catalog).
>>
>> This provides some (heat specific) information which may help somewhat:
>>
>>
>> http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html
>>
>> >     3. Trust mechanism itself is in development and cana**t be used at
>> this
>> >        point.
>>
>> IME trusts work fine, Heat has been using them since Havana with few
>> problems.
>>
>> >     4. OpenStack clients need to be changed in some way to somehow
>> bypass
>> >        this keystone limitation?
>>
>> AFAICS it's not a keystone limitation, the behavior you're seeing is
>> expected, and the 403 mentioned by Nikolay is just trusts working as
>> designed.
>>
>> The key thing from a client perspective is:
>>
>> 1. If you pass a trust-scoped token into the client, you must not request
>> another token, normally this means you must provide an endpoint as you
>> can't run the normal auth code which retrieves the service catalog.
>>
>> 2. If you could pass a trust ID in, with a non-trust-scoped token, or
>> username/password, the above limitation is removed, but AFAIK none of the
>> CLI interfaces support a trust ID yet.
>>
>> 3. If you're using a trust scoped token, you cannot create another trust
>> (unless you've enabled chained delegation, which only landed recently in
>> keystone).  This means, for example, that you can't create a heat stack
>> with a trust scoped token (when heat is configured to use trusts), unless
>> you use chained delegation, because we create a trust internally.
>>
>> When you understand these constraints, it's definitely possible to create
>> a
>> trust and use it for requests to other services, for example, here's how
>> you could use a trust-scoped token to call heat:
>>
>> heat --os-auth-token <trust-scoped-token> --os-no-client-auth
>> --heat-url http://192.168.0.4:8004/v1/<project-id> stack-list
>>
>> The pattern heat uses internally to work with trusts is:
>>
>> 1. Use a trust_id and service user credentials to get a trust scoped token
>> 2. Pass the trust-scoped token into python clients for other projects,
>> using the endpoint obtained during (1)
>>
>> This works fine, what you can't do is pass the trust scoped token in
>> without explicitly defining the endpoint, because this triggers
>> reauthentication, which as you've discovered, won't work.
>>
>> Hope that helps!
>>
>> Steve
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> Kind Regards,
> Alexander Makarov,
> Senoir 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
>



-- 
Kind Regards,
Alexander Makarov,
Senoir 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/20150216/58799183/attachment.html>