Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

@Renat, I like the idea. For now we have a spec:
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst
It's consiedered to be enough but as for me it lacks TL;DR section :)

On Thu, Feb 19, 2015 at 8:15 PM, Renat Akhmerov 
wrote:

>
> On 19 Feb 2015, at 18:32, Alexander Makarov  wrote:
>
> @Renat, They are conceptually different:
> - regular tokens are created for the owner of addressed resource
> - trust scoped tokens are for trustees and have some security restrictions.
> The case is about disallowing a trustee to aquire a regular token allowing
> him anything the trustor is allowed. It'd be an exploit.
>
>
> Alexander,
>
> Thanks for explanations. I kind of get the general idea, yes. What is best
> source where we could go and read in details about that? The only page I
> was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts but
> it would be nice if something more tutorial-like existed.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> 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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Renat Akhmerov]

> On 19 Feb 2015, at 18:32, Alexander Makarov  wrote:
> 
> @Renat, They are conceptually different:
> - regular tokens are created for the owner of addressed resource
> - trust scoped tokens are for trustees and have some security restrictions.
> The case is about disallowing a trustee to aquire a regular token allowing 
> him anything the trustor is allowed. It'd be an exploit.


Alexander,

Thanks for explanations. I kind of get the general idea, yes. What is best 
source where we could go and read in details about that? The only page I was 
able to find is https://wiki.openstack.org/wiki/Keystone/Trusts 
 but it would be nice if 
something more tutorial-like existed.

Renat Akhmerov
@ Mirantis Inc.

__
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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov 
wrote:

> Hi,
>
>
> > On 18 Feb 2015, at 23:54, Nikolay Makhotkin 
> wrote:
> >
> > Nova client's CLI parameter 'bypass_url' helps me. The client's API also
> has 'management_url' attribute, if this one is specified - the client
> doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
> so client doesn't make extra call to keystone to retrieve new token and
> service_catalog.
> >
> > Thank you for clarification!
>
>
> I want to say an additional “thank you” from me for helping us solve this
> problem that’s been around for a while.
>
> And just a small conceptual question: in my understanding since trust
> chaining has already landed this kind of reauthentication doesn’t make a
> lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped
> tokens a regular tokens should be considered equal? Or we should still
> assume that trust scoped tokens are sort of limited? If yes then how
> exactly they must be understood?
>
>
> Thanks!
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> 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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Renat Akhmerov]

Hi,


> On 18 Feb 2015, at 23:54, Nikolay Makhotkin  wrote:
> 
> Nova client's CLI parameter 'bypass_url' helps me. The client's API also has 
> 'management_url' attribute, if this one is specified - the client doesn't 
> reauthenticate. Also the most of clients have 'endpoint' argument, so client 
> doesn't make extra call to keystone to retrieve new token and service_catalog.
> 
> Thank you for clarification!


I want to say an additional “thank you” from me for helping us solve this 
problem that’s been around for a while.

And just a small conceptual question: in my understanding since trust chaining 
has already landed this kind of reauthentication doesn’t make a lot of sense to 
me. Isn’t trust chaining supposed to mean that trust-scoped tokens a regular 
tokens should be considered equal? Or we should still assume that trust scoped 
tokens are sort of limited? If yes then how exactly they must be understood?


Thanks!

Renat Akhmerov
@ Mirantis Inc.


__
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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Nikolay Makhotkin]

Hello!

Nova client's CLI parameter 'bypass_url' helps me. The client's API also
has 'management_url' attribute, if this one is specified - the client
doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
so client doesn't make extra call to keystone to retrieve new token and
service_catalog.

Thank you for clarification!


On Mon, Feb 16, 2015 at 11:30 PM, Jamie Lennox 
wrote:

>
>
> - Original Message -
> > From: "Alexander Makarov" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Tuesday, 17 February, 2015 4:00:05 AM
> > Subject: Re: [openstack-dev] [keystone] [trusts] [all] How trusts should
> work by design?
> >
> >
> 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  --os-no-client-auth
> > --heat-url http://192.168.0.4:8004/v1/  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)
> >
>

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Jamie Lennox]

- Original Message -
> From: "Alexander Makarov" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, 17 February, 2015 4:00:05 AM
> Subject: Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work 
> by design?
> 
> 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  --os-no-client-auth
> --heat-url http://192.168.0.4:8004/v1/  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
> 

So I think what you are seeing, and what heat has come up against in the past 
is a limitation of the various python-*clients and not a problem of the actual 
delegation mechanism from the keystone point of view. This is a result of the 
basic authentication code being copied around between clients and then not 
being kept updated since... probably havana.

The good news is that if you go with the session based approach then you can 
share these tokens amongst clients without the hacks. 

The identity authentication plugins that keystoneclient offers (v2 and v3 api 
for Token and Password) both accept a trust_id to be scoped to and then the 
plugin can be shared a

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Renat Akhmerov]

Steve, I saw a couple of things in what you wrote that we might be doing wrong. 
We’ll check them when we wake up and let you know what we discovered. 

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 16 Feb 2015, at 21:47, Steven Hardy  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  --os-no-client-auth
> --heat-url http://192.168.0.4:8004/v1/ 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


__
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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication

On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov 
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  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  --os-no-client-auth
>> --heat-url http://192.168.0.4:8004/v1/ 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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

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  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  --os-no-client-auth
> --heat-url http://192.168.0.4:8004/v1/ 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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Steven Hardy]

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  --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Renat Akhmerov]

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?

Thanks

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-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] 
> https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
>  
> 
> 
>  
> Best Regards,
> Nikolay Makhotkin
> @Mirantis
> __
> 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

__
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