https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication
On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov <amaka...@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 <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 > -- 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