Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150216/02730020/attachment.html>