Yeah, clarification from keystone folks would be really helpful.

If Nikolay’s info is correct (I believe it is) then I actually don’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 didn’t checked that yet myself.

So please help us understand which one of my following assumptions is correct?

We don’t understand what trusts are.
We use them in a wrong way. (If yes, then what’s the correct usage?)
Trust mechanism itself is in development and can’t be used at this point.
OpenStack clients need to be changed in some way to somehow bypass this 
keystone limitation?


Renat Akhmerov
@ Mirantis Inc.

> On 16 Feb 2015, at 19:10, Nikolay Makhotkin <> wrote:
> Hello, 
> Decided to start a new thread due to too much technical details in old 
> thread. 
> (You can see thread [openstack-dev] [keystone] [nova] )
> The problem: Trusts can not be used to retrieve a token for further work with 
> python-<project>client.
> I made some research for trust's use cases. The main goal of trusts is clear 
> to me: delegation of privileges of one user to another on specific time (or 
> limitless). But if I get a trust and then get a token from it, it can not be 
> used in any python-client. The reason why it happens so - is 'authenticate' 
> method in almost all python-clients. This method request a keystone for 
> authentication and get a new auth token. But in case of trust-scoped token it 
> can't be true - this method always return '403 Forbidden' [1]
> The question: Is there a way to create a trust and use it for requests to any 
> other service? E.g., We can get a token from trust and use it (but actually, 
> we are not).
> Or am I misunderstanding trust's purpose? How are trusts should worked?
> [1] 
> <>
> Best Regards,
> Nikolay Makhotkin
> @Mirantis
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to