settingsLogin | Registersettings

[openstack-dev] [keystone] [nova]

0 votes

Hi !

I investigated trust's use cases and encountered the problem: When I use
auth_token obtained from keystoneclient using trust, I get *403* Forbidden
error: *You are not authorized to perform the requested action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from master,
    tried also to use stable/icehouse)
  • Import v3 novaclient
  • initialize the keystoneclient:
    keystone = keystoneclient.Client(username=username, password=password,
    tenantname=tenantname, authurl=authurl)

  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id, authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just can
work with nova like it was initialized using direct token.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Feb 11, 2015 in openstack-dev by Nikolay_Makhotkin (2,300 points)   4 7
retagged Feb 25, 2015 by admin

8 Responses

0 votes

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
Hi !

I investigated trust's use cases and encountered the problem: When I
use auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from
    master, tried also to use stable/icehouse)
  • Import v3 novaclient
  • initialize the keystoneclient:
    keystone = keystoneclient.Client(username=username,
    password=password, tenantname=tenantname, authurl=authurl)

  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id , authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just
can work with nova like it was initialized using direct token.

From what you wrote here it should work, but since Heat has been doing
stuff like this for a while, I'm pretty sure it is your setup and not a
fundamental problem.

I'd take a look at what is going back and forth on the wire and make
sure the right token is being sent to Nova. If it is the original users
token and not the trust token, then you would see that error.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 11, 2015 by Adam_Young (19,940 points)   2 7 10
0 votes

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem: When I use
auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested
action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from
    master, tried also to use stable/icehouse)

    • Import v3 novaclient
    • initialize the keystoneclient:
      keystone = keystoneclient.Client(username=username, password=password,
      tenantname=tenantname, authurl=authurl)
  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id, authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just can
work with nova like it was initialized using direct token.

From what you wrote here it should work, but since Heat has been doing
stuff like this for a while, I'm pretty sure it is your setup and not a
fundamental problem.

I'd take a look at what is going back and forth on the wire and make sure
the right token is being sent to Nova. If it is the original users token
and not the trust token, then you would see that error.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 11, 2015 by Nikolay_Makhotkin (2,300 points)   4 7
0 votes

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:
No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

The original user needs to have the appropriate role to perform the
operation on the specified project. I see the admin role is created on
the trust. If the trustor did not have that role, the trustee would not
be able to exececute the trust and get a token. It looks like you were
able to execute the trust and get a token, but I would like you to
confirm that, and not just trust the keystone client: either put debug
statements in Keystone or call the POST to tokens from curl with the
appropriate options to get a trust token. In short, make sure you have
not fooled yourself. You can also look in the token table inside
Keystone to see the data for the trust token, or validate the token via
curl to see the data in it. In all cases, there should be an OS-TRUST
stanza in the token data.

If it is still failing, there might be some issue on the Policy side. I
have been assuming that you are running with the default policy for Nova.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer input
would be appreciated) but I'm guessing it is executing the rule
|
"adminorowner": "isadmin:True or projectid:%(project_id)s",

Since that is the default. I am guessing that the project_id in question
comes from the token here, as that seems to be common, but if not, it
might be that the two values are mismatched. Perhaps there Proejct ID
value from the client env var is sent, and matches what the trustor
normally works as, not the project in question. If these two values
don't match, then, yes, the rule would fail.
|

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young <ayoung@redhat.com
ayoung@redhat.com> wrote:

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
Hi !

I investigated trust's use cases and encountered the problem:
When I use auth_token obtained from keystoneclient using trust, I
get *403* Forbidden error: *You are not authorized to perform the
requested action.*

Steps to reproduce:

- Import v3 keystoneclient (used keystone and keystoneclient from
master, tried also to use stable/icehouse)
- Import v3 novaclient
- initialize the keystoneclient:
 keystone = keystoneclient.Client(username=username,
password=password, tenant_name=tenant_name, auth_url=auth_url)

- create a trust:
  trust = keystone.trusts.create(
keystone.user_id,
keystone.user_id,
impersonation=True,
role_names=['admin'],
project=keystone.project_id
  )

- initialize new keystoneclient:
  client_from_trust = keystoneclient.Client(
    username=username, password=password,
    trust_id=trust.id , auth_url=auth_url,
  )

- create nova client using new token from new client:
  nova = novaclient.Client(
auth_token=client_from_trust.auth_token,
    auth_url=auth_url_v2,
    project_id=from_trust.project_id,
    service_type='compute',
    username=None,
    api_key=None
  )

- do simple request to nova:
nova.servers.list()

- get the error described above.


Maybe I misunderstood something but what is wrong? I supposed I
just can work with nova like it was initialized using direct token.
From what you wrote here it should work, but since Heat has been
doing stuff like this for a while, I'm pretty sure it is your
setup and not a fundamental problem.

I'd take a look at what is going back and forth on the wire and
make sure the right token is being sent to Nova. If it is the
original users token and not the trust token, then you would see
that error.
-- 
Best Regards,
Nikolay


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 11, 2015 by Adam_Young (19,940 points)   2 7 10
0 votes

A trust token cannot be used to get another token:
https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
You have to make your Nova client use the very same trust scoped token
obtained from authentication using trust without trying to authenticate
with it one more time.

On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

The original user needs to have the appropriate role to perform the
operation on the specified project. I see the admin role is created on the
trust. If the trustor did not have that role, the trustee would not be able
to exececute the trust and get a token. It looks like you were able to
execute the trust and get a token, but I would like you to confirm that,
and not just trust the keystone client: either put debug statements in
Keystone or call the POST to tokens from curl with the appropriate options
to get a trust token. In short, make sure you have not fooled yourself.
You can also look in the token table inside Keystone to see the data for
the trust token, or validate the token via curl to see the data in it. In
all cases, there should be an OS-TRUST stanza in the token data.

If it is still failing, there might be some issue on the Policy side. I
have been assuming that you are running with the default policy for Nova.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer input
would be appreciated) but I'm guessing it is executing the rule

"adminorowner": "isadmin:True or projectid:%(project_id)s",

Since that is the default. I am guessing that the project_id in question
comes from the token here, as that seems to be common, but if not, it might
be that the two values are mismatched. Perhaps there Proejct ID value from
the client env var is sent, and matches what the trustor normally works as,
not the project in question. If these two values don't match, then, yes,
the rule would fail.

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem: When I
use auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested
action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from
    master, tried also to use stable/icehouse)

    • Import v3 novaclient
    • initialize the keystoneclient:
      keystone = keystoneclient.Client(username=username, password=password,
      tenantname=tenantname, authurl=authurl)
  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id, authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just can
work with nova like it was initialized using direct token.

From what you wrote here it should work, but since Heat has been doing
stuff like this for a while, I'm pretty sure it is your setup and not a
fundamental problem.

I'd take a look at what is going back and forth on the wire and make sure
the right token is being sent to Nova. If it is the original users token
and not the trust token, then you would see that error.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 12, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

On 02/12/2015 10:40 AM, Alexander Makarov wrote:
A trust token cannot be used to get another token:
https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
You have to make your Nova client use the very same trust scoped token
obtained from authentication using trust without trying to
authenticate with it one more time.

Actually, there have been some recent changes to allow re-delegation of
Trusts, but for older deployments, you are correct. I hadn't seen
anywhere here that he was trying to use a trust token to get another
token, though.

On Wed, Feb 11, 2015 at 9:10 PM, Adam Young <ayoung@redhat.com
ayoung@redhat.com> wrote:

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:
No, I just checked it. Nova receives trust token and raise this
error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's
token.
The original user needs to have the appropriate role to perform
the operation on the specified project.  I see the admin role is
created on the trust. If the trustor did not have that role, the
trustee would not be able to exececute the trust and get a token. 
It looks like you were able to execute the trust and get a token, 
but I would like you to confirm that, and not just trust the
keystone client:  either put debug statements in Keystone or call
the POST to tokens from curl with the appropriate options to get a
trust token.  In short, make sure you have not fooled yourself. 
You can also look in the token table inside Keystone to see the
data for the trust token, or validate the token  via curl to see
the data in it.  In all cases, there should be an OS-TRUST stanza
in the token data.


If it is still failing, there might be some issue on the Policy
side.  I have been assuming that you are running with the default
policy for Nova.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer
input would be appreciated)  but I'm guessing it is executing the
rule
|
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",

Since that is the default. I am guessing that the project_id in
question comes from the token here, as that seems to be common,
but if not, it might be that the two values are mismatched.
Perhaps there Proejct ID value from the client env var is sent,
and matches what the trustor normally works as, not the project in
question.  If these two values don't match, then, yes, the rule
would fail.
|
On Wed, Feb 11, 2015 at 7:55 PM, Adam Young <ayoung@redhat.com
<mailto:ayoung@redhat.com>> wrote:

    On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
    Hi !

    I investigated trust's use cases and encountered the
    problem: When I use auth_token obtained from keystoneclient
    using trust, I get *403* Forbidden error: *You are not
    authorized to perform the requested action.*

    Steps to reproduce:

    - Import v3 keystoneclient (used keystone and keystoneclient
    from master, tried also to use stable/icehouse)
    - Import v3 novaclient
    - initialize the keystoneclient:
     keystone = keystoneclient.Client(username=username,
    password=password, tenant_name=tenant_name, auth_url=auth_url)

    - create a trust:
      trust = keystone.trusts.create(
      keystone.user_id,
      keystone.user_id,
      impersonation=True,
      role_names=['admin'],
      project=keystone.project_id
    )

    - initialize new keystoneclient:
      client_from_trust = keystoneclient.Client(
        username=username, password=password,
        trust_id=trust.id , auth_url=auth_url,
      )

    - create nova client using new token from new client:
      nova = novaclient.Client(
    auth_token=client_from_trust.auth_token,
        auth_url=auth_url_v2,
    project_id=from_trust.project_id,
        service_type='compute',
        username=None,
        api_key=None
      )

    - do simple request to nova:
    nova.servers.list()

    - get the error described above.


    Maybe I misunderstood something but what is wrong? I
    supposed I just can work with nova like it was initialized
    using direct token.
    From what you wrote here it should work, but since Heat has
    been doing stuff like this for a while, I'm pretty sure it is
    your setup and not a fundamental problem.

    I'd take a look at what is going back and forth on the wire
    and make sure the right token is being sent to Nova.  If it
    is the original users token and not the trust token, then you
    would see that error.
    -- 
    Best Regards,
    Nikolay


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




-- 
Best Regards,
Nikolay


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 12, 2015 by Adam_Young (19,940 points)   2 7 10
0 votes

Adam, Nova client does it for some reason during a call to
nova.servers.list()

On Thu, Feb 12, 2015 at 10:03 PM, Adam Young ayoung@redhat.com wrote:

On 02/12/2015 10:40 AM, Alexander Makarov wrote:

A trust token cannot be used to get another token:

https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
You have to make your Nova client use the very same trust scoped token
obtained from authentication using trust without trying to authenticate
with it one more time.

Actually, there have been some recent changes to allow re-delegation of
Trusts, but for older deployments, you are correct. I hadn't seen anywhere
here that he was trying to use a trust token to get another token, though.

On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

The original user needs to have the appropriate role to perform the
operation on the specified project. I see the admin role is created on the
trust. If the trustor did not have that role, the trustee would not be able
to exececute the trust and get a token. It looks like you were able to
execute the trust and get a token, but I would like you to confirm that,
and not just trust the keystone client: either put debug statements in
Keystone or call the POST to tokens from curl with the appropriate options
to get a trust token. In short, make sure you have not fooled yourself.
You can also look in the token table inside Keystone to see the data for
the trust token, or validate the token via curl to see the data in it. In
all cases, there should be an OS-TRUST stanza in the token data.

If it is still failing, there might be some issue on the Policy side. I
have been assuming that you are running with the default policy for Nova.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer input
would be appreciated) but I'm guessing it is executing the rule

"adminorowner": "isadmin:True or projectid:%(project_id)s",

Since that is the default. I am guessing that the project_id in question
comes from the token here, as that seems to be common, but if not, it might
be that the two values are mismatched. Perhaps there Proejct ID value from
the client env var is sent, and matches what the trustor normally works as,
not the project in question. If these two values don't match, then, yes,
the rule would fail.

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem: When I
use auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested
action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from
    master, tried also to use stable/icehouse)

    • Import v3 novaclient
    • initialize the keystoneclient:
      keystone = keystoneclient.Client(username=username,
      password=password, tenantname=tenantname, authurl=authurl)
  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id, authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just can
work with nova like it was initialized using direct token.

From what you wrote here it should work, but since Heat has been doing
stuff like this for a while, I'm pretty sure it is your setup and not a
fundamental problem.

I'd take a look at what is going back and forth on the wire and make
sure the right token is being sent to Nova. If it is the original users
token and not the trust token, then you would see that error.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 13, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

Well, if we use trust-scoped token for getting server-list from nova
(simply use nova.servers.list() ),

Novaclient somehow tries to get another token:
https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L690-L724

Actually, novaclient does this request: (found from debug of novaclient)

REQ: curl -i 'http://:5000/v2.0/tokens' -X POST -H "Accept:
application/json" -H "Content-Type: application/json" -H "User-Agent:
python-novaclient" -d '{"auth": {"token": {"id":
"78c71fb549244075b3a5d994baa326b3"}, "tenantName":
"b0c9bbb541d541b098c3c0a92412720d"}}'

I.e., this is the request for another auth token from keystone. Keystone
here returns 403 because token in request is trust-scoped.

Why I can't do this simple command using trust-scoped token?

Note: Doing the keystone --os-token 5483086d91094a3886ccce1442b538a0
--os-endpoint http://:5000/v2.0 tenant-list, it returns
tenant-list (not 403).
Note2: Doing the server-list request directly to api with trust-scoped
token, it returns 200, not 403:

curl -H "X-Auth-Token: 5483086d91094a3886ccce1442b538a0"
http://192.168.0.2:8774/v3/servers

{
"servers": [ ]
}

How I can use trust-scoped tokrn via client?

On Fri, Feb 13, 2015 at 9:16 PM, Alexander Makarov amakarov@mirantis.com
wrote:

Adam, Nova client does it for some reason during a call to
nova.servers.list()

On Thu, Feb 12, 2015 at 10:03 PM, Adam Young ayoung@redhat.com wrote:

On 02/12/2015 10:40 AM, Alexander Makarov wrote:

A trust token cannot be used to get another token:

https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
You have to make your Nova client use the very same trust scoped token
obtained from authentication using trust without trying to authenticate
with it one more time.

Actually, there have been some recent changes to allow re-delegation of
Trusts, but for older deployments, you are correct. I hadn't seen anywhere
here that he was trying to use a trust token to get another token, though.

On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

The original user needs to have the appropriate role to perform the
operation on the specified project. I see the admin role is created on the
trust. If the trustor did not have that role, the trustee would not be able
to exececute the trust and get a token. It looks like you were able to
execute the trust and get a token, but I would like you to confirm that,
and not just trust the keystone client: either put debug statements in
Keystone or call the POST to tokens from curl with the appropriate options
to get a trust token. In short, make sure you have not fooled yourself.
You can also look in the token table inside Keystone to see the data for
the trust token, or validate the token via curl to see the data in it. In
all cases, there should be an OS-TRUST stanza in the token data.

If it is still failing, there might be some issue on the Policy side. I
have been assuming that you are running with the default policy for Nova.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer input
would be appreciated) but I'm guessing it is executing the rule

"adminorowner": "isadmin:True or projectid:%(project_id)s",

Since that is the default. I am guessing that the project_id in question
comes from the token here, as that seems to be common, but if not, it might
be that the two values are mismatched. Perhaps there Proejct ID value from
the client env var is sent, and matches what the trustor normally works as,
not the project in question. If these two values don't match, then, yes,
the rule would fail.

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayoung@redhat.com wrote:

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem: When I
use auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested
action.*

Steps to reproduce:

  • Import v3 keystoneclient (used keystone and keystoneclient from
    master, tried also to use stable/icehouse)

    • Import v3 novaclient
    • initialize the keystoneclient:
      keystone = keystoneclient.Client(username=username,
      password=password, tenantname=tenantname, authurl=authurl)
  • create a trust:
    trust = keystone.trusts.create(
    keystone.userid,
    keystone.user
    id,
    impersonation=True,
    rolenames=['admin'],
    project=keystone.project
    id
    )

  • initialize new keystoneclient:
    clientfromtrust = keystoneclient.Client(
    username=username, password=password,
    trustid=trust.id, authurl=auth_url,
    )

  • create nova client using new token from new client:
    nova = novaclient.Client(
    authtoken=clientfromtrust.authtoken,
    authurl=authurlv2,
    project
    id=fromtrust.projectid,
    servicetype='compute',
    username=None,
    api
    key=None
    )

  • do simple request to nova:
    nova.servers.list()

  • get the error described above.

Maybe I misunderstood something but what is wrong? I supposed I just
can work with nova like it was initialized using direct token.

From what you wrote here it should work, but since Heat has been
doing stuff like this for a while, I'm pretty sure it is your setup and not
a fundamental problem.

I'd take a look at what is going back and forth on the wire and make
sure the right token is being sent to Nova. If it is the original users
token and not the trust token, then you would see that error.

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Nikolay_Makhotkin (2,300 points)   4 7
0 votes

On 02/16/2015 05:00 AM, Nikolay Makhotkin wrote:
Well, if we use trust-scoped token for getting server-list from nova
(simply use nova.servers.list() ),

Novaclient somehow tries to get another token:
https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L690-L724

Actually, novaclient does this request: (found from debug of novaclient)
So this sounds like a bug in Nova client. Jamie Lennox has been working
with the various client teams to get the using the Auth plugin
architecture and session management from Keystone client to try and make
the usage consistent.

REQ: curl -i 'http://:5000/v2.0/tokens' -X POST -H "Accept:
application/json" -H "Content-Type: application/json" -H "User-Agent:
python-novaclient" -d '{"auth": {"token": {"id":
"78c71fb549244075b3a5d994baa326b3"}, "tenantName":
"b0c9bbb541d541b098c3c0a92412720d"}}'

I.e., this is the request for another auth token from keystone.
Keystone here returns 403 because token in request is trust-scoped.

Why I can't do this simple command using trust-scoped token?

Note: Doing the keystone --os-token 5483086d91094a3886ccce1442b538a0
--os-endpoint http://:5000/v2.0 tenant-list, it returns
tenant-list (not 403).
Note2: Doing the server-list request directly to api with trust-scoped
token, it returns 200, not 403:

curl -H "X-Auth-Token: 5483086d91094a3886ccce1442b538a0"
http://192.168.0.2:8774/v3/servers

{
"servers": [ ]
}

How I can use trust-scoped tokrn via client?

On Fri, Feb 13, 2015 at 9:16 PM, Alexander Makarov
<amakarov@mirantis.com amakarov@mirantis.com> wrote:

Adam, Nova client does it for some reason during a call to
nova.servers.list()


On Thu, Feb 12, 2015 at 10:03 PM, Adam Young <ayoung@redhat.com
<mailto:ayoung@redhat.com>> wrote:

    On 02/12/2015 10:40 AM, Alexander Makarov wrote:
    A trust token cannot be used to get another token:
    https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
    You have to make your Nova client use the very same trust
    scoped token obtained from authentication using trust without
    trying to authenticate with it one more time.
    Actually, there have been some recent changes to allow
    re-delegation of Trusts, but for older deployments, you are
    correct.  I hadn't seen anywhere here that he was trying to
    use a trust token to get another token, though.
    On Wed, Feb 11, 2015 at 9:10 PM, Adam Young
    <ayoung@redhat.com <mailto:ayoung@redhat.com>> wrote:

        On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:
        No, I just checked it. Nova receives trust token and
        raise this error.

        In my script, I see:

        http://paste.openstack.org/show/171452/

        And as you can see, token from trust differs from direct
        user's token.
        The original user needs to have the appropriate role to
        perform the operation on the specified project.  I see
        the admin role is created on the trust. If the trustor
        did not have that role, the trustee would not be able to
        exececute the trust and get a token.  It looks like you
        were able to execute the trust and get a token,  but I
        would like you to confirm that, and not just trust the
        keystone client:  either put debug statements in Keystone
        or call the POST to tokens from curl with the appropriate
        options to get a trust token.  In short, make sure you
        have not fooled yourself.  You can also look in the token
        table inside Keystone to see the data for the trust
        token, or validate the token  via curl to see the data in
        it.  In all cases, there should be an OS-TRUST stanza in
        the token data.


        If it is still failing, there might be some issue on the
        Policy side.  I have been assuming that you are running
        with the default policy for Nova.

        http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

        I'm not sure which rule matches for list servers (Nova
        developer input would be appreciated)  but I'm guessing
        it is executing the rule
        |
        "admin_or_owner": "is_admin:True or
        project_id:%(project_id)s",

        Since that is the default. I am guessing that the
        project_id in question comes from the token here, as that
        seems to be common, but if not, it might be that the two
        values are mismatched. Perhaps there Proejct ID value
        from the client env var is sent, and matches what the
        trustor normally works as, not the project in question. 
        If these two values don't match, then, yes, the rule
        would fail.
        |
        On Wed, Feb 11, 2015 at 7:55 PM, Adam Young
        <ayoung@redhat.com <mailto:ayoung@redhat.com>> wrote:

            On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
            Hi !

            I investigated trust's use cases and encountered
            the problem: When I use auth_token obtained from
            keystoneclient using trust, I get *403* Forbidden
            error: *You are not authorized to perform the
            requested action.*

            Steps to reproduce:

            - Import v3 keystoneclient (used keystone and
            keystoneclient from master, tried also to use
            stable/icehouse)
            - Import v3 novaclient
            - initialize the keystoneclient:
             keystone =
            keystoneclient.Client(username=username,
            password=password, tenant_name=tenant_name,
            auth_url=auth_url)

            - create a trust:
              trust = keystone.trusts.create(
            keystone.user_id,
            keystone.user_id,
            impersonation=True,
            role_names=['admin'],
            project=keystone.project_id
            )

            - initialize new keystoneclient:
            client_from_trust = keystoneclient.Client(
            username=username, password=password,
            trust_id=trust.id , auth_url=auth_url,
              )

            - create nova client using new token from new client:
              nova = novaclient.Client(
            auth_token=client_from_trust.auth_token,
            auth_url=auth_url_v2,
            project_id=from_trust.project_id,
            service_type='compute',
            username=None,
            api_key=None
              )

            - do simple request to nova:
            nova.servers.list()

            - get the error described above.


            Maybe I misunderstood something but what is wrong?
            I supposed I just can work with nova like it was
            initialized using direct token.
            From what you wrote here it should work, but since
            Heat has been doing stuff like this for a while, I'm
            pretty sure it is your setup and not a fundamental
            problem.

            I'd take a look at what is going back and forth on
            the wire and make sure the right token is being sent
            to Nova. If it is the original users token and not
            the trust token, then you would see that error.
            -- 
            Best Regards,
            Nikolay


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




        -- 
        Best Regards,
        Nikolay


        __________________________________________________________________________
        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Adam_Young (19,940 points)   2 7 10
...