Open Stack

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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/c01f90ec/attachment.html>