On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov <amaka...@mirantis.com>
> 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 <sha...@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
>> > 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
>> 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:
>> > 3. Trust mechanism itself is in development and cana**t be used at
>> > point.
>> IME trusts work fine, Heat has been using them since Havana with few
>> > 4. OpenStack clients need to be changed in some way to somehow
>> > 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
>> 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
>> 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!
>> OpenStack Development Mailing List (not for usage questions)
> 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
Senoir Software Developer,
35b/3, Vorontsovskaya St., 109147, Moscow, Russia
Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60
OpenStack Development Mailing List (not for usage questions)