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 > 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-requ...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
