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

2015-02-19 Thread 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 rakhme...@mirantis.com
wrote:

 Hi,


  On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhot...@mirantis.com
 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?

2015-02-19 Thread 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 rakhme...@mirantis.com
wrote:


 On 19 Feb 2015, at 18:32, Alexander Makarov amaka...@mirantis.com 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?

2015-02-19 Thread Renat Akhmerov

 On 19 Feb 2015, at 18:32, Alexander Makarov amaka...@mirantis.com 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 
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?

2015-02-18 Thread 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 jamielen...@redhat.com
wrote:



 - Original Message -
  From: Alexander Makarov amaka...@mirantis.com
  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 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
 

 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

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

2015-02-18 Thread Renat Akhmerov
Hi,


 On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhot...@mirantis.com 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?

2015-02-16 Thread 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 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


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

2015-02-16 Thread 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 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


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

2015-02-16 Thread Alexander Makarov
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


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

2015-02-16 Thread 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 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


__
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?

2015-02-16 Thread Jamie Lennox


- Original Message -
 From: Alexander Makarov amaka...@mirantis.com
 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 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
 

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 amongst all the clients that support it (AFAIK that's 
almost everyone - the big exceptions being glance and swift). 

Here's an example (untested - off the top of my head):

from keystoneclient import session 
from keystoneclient.auth.identity import v3 
from cinderclient.v2 import client as c_client
from keystoneclient.v3 import client as k_client
from novaclient.v1_1 import client as n_client

a = v3.Password(auth_url='http

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

2015-02-16 Thread Nikolay Makhotkin
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-projectclient.

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


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

2015-02-16 Thread 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 nmakhot...@mirantis.com 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-projectclient.
 
 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
  
 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