Open Stack

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 at redhat.com 
> <mailto: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
>>     <mailto: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 <http://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:unsubscribe  <mailto:OpenStack-dev-request at 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 at lists.openstack.org?subject:unsubscribe
>>         <http://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 at lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request at 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 at lists.openstack.org?subject:unsubscribe
>     <http://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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/f5b79dbe/attachment.html>