Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients
- Original Message - From: michael mccune m...@redhat.com To: openstack-dev@lists.openstack.org Sent: Friday, August 7, 2015 1:21:53 AM Subject: Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients On 08/05/2015 10:27 PM, Jamie Lennox wrote: Hey Mike, I think it could be one of the hacks that are in place to try and keep compatibility with the old and new way of using the client is returning the wrong thing. Compare the output of trustor.user_id and trustor_auth.get_user_id(sess). For me trustor.user_id is None which will make sense why you'd get permission errors. Whether this is a bug in keystoneclient is debatable because we had to keep compatibility with the old options just not update them for the new paths, the ambiguity is certainly bad. The command that works for me is: trustor.trusts.create( trustor_user=trustor_auth.get_user_id(sess), trustee_user=trustee_auth.get_user_id(sess), project=trustor_auth.get_project_id(sess), role_names=['Member'], impersonation=True, expires_at=None) We're working on a keystoneclient 2.0 that will remove all that old code. Let me know if that fixes it for you. hi Jamie, this does work for me. but now i have a few questions as i start to refactor our code. Great previously we have been handing around keystone Client objects to perform all of our operations. this leads to some trouble as we expected the user_id, and project_id, to be present in the client. so, 3 questions. 1. is it safe to set the user_id and project_id on a Client object? (i notice that i am able to perform this operation and it would make things slightly easier to refactor) It's safe in that if you force set it on the client then there isn't anything in the client that will override it, I don't know if i'd recommend it though. 2. are there plans for the new keystoneclient to automatically fill in user_id and project_id for Session/Auth based clients? No 3. would it be better to transform our code to pass around Auth plugin objects instead of Client objects? Absolutely. So conceptually this is what we're trying to get to with keystoneclient. Keystone has 2 related but distinct jobs, one is to provide authentication for all the services and one is to manage it's own CRUD operations. Using sessions and auth plugins are authentication opreations and the existing keystoneclient should be used only for keystone's CRUD operations. This is the also the intent behind the upcoming keystoneauth/keystoneclient split where authentication options that are common to all clients are going to get moved to keystoneauth. If you find yourself using a keystoneclient object for auth I would consider that a bug. There is a larger question here about what sahara is doing with the user_id and project_id, typically this would be received from auth_token middleware or otherwise be implied by the token that is passed around. If you are passing these parameters to other clients we should fix those clients. For most projects this is handled by passing around the Context object which contains a session, a plugin and all the information from auth_token middleware. thanks again for the help, mike __ 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] policy issues when generating trusts with different clients
On 08/05/2015 10:27 PM, Jamie Lennox wrote: Hey Mike, I think it could be one of the hacks that are in place to try and keep compatibility with the old and new way of using the client is returning the wrong thing. Compare the output of trustor.user_id and trustor_auth.get_user_id(sess). For me trustor.user_id is None which will make sense why you'd get permission errors. Whether this is a bug in keystoneclient is debatable because we had to keep compatibility with the old options just not update them for the new paths, the ambiguity is certainly bad. The command that works for me is: trustor.trusts.create( trustor_user=trustor_auth.get_user_id(sess), trustee_user=trustee_auth.get_user_id(sess), project=trustor_auth.get_project_id(sess), role_names=['Member'], impersonation=True, expires_at=None) We're working on a keystoneclient 2.0 that will remove all that old code. Let me know if that fixes it for you. hi Jamie, this does work for me. but now i have a few questions as i start to refactor our code. previously we have been handing around keystone Client objects to perform all of our operations. this leads to some trouble as we expected the user_id, and project_id, to be present in the client. so, 3 questions. 1. is it safe to set the user_id and project_id on a Client object? (i notice that i am able to perform this operation and it would make things slightly easier to refactor) 2. are there plans for the new keystoneclient to automatically fill in user_id and project_id for Session/Auth based clients? 3. would it be better to transform our code to pass around Auth plugin objects instead of Client objects? thanks again for the help, mike __ 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] policy issues when generating trusts with different clients
I think this is happening because the last session created was based off
of trustee_auth. Try creating 2 sessions, one for each user (trustor and
trustee). Maybe Jamie will chime in.
Thanks,
Steve Martinelli
OpenStack Keystone Core
michael mccune m...@redhat.com wrote on 2015/08/03 07:11:34 PM:
From: michael mccune m...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 2015/08/03 07:12 PM
Subject: [openstack-dev] [keystone] policy issues when generating
trusts with different clients
hi all,
i am doing some work to change sahara to make greater use of
keystoneclient.session.Session objects and i am running into a strange
error when issuing the trusts.
the crux of this issue is that when i create Client objects by passing
all the parameters directly to the client, the trust is created as
normal. But, if i create a Password based auth plugin object, using the
same parameters, and the instantiate a Client by using the auth and a
Session object, then i fail to create the trust with an error about not
having sufficient permission.
i have put together a few python repl samples to show what is happening,
these are also available on github[1].
the following code shows how we've been doing this, using the generic
Client object we authenticate using the named parameters.
from keystoneclient.v3 import client
trustor = client.Client(
auth_url='http://192.168.122.2:5000/v3',
username='demo',
password='openstack',
project_name='demo',
user_domain_name='Default',
project_domain_name='Default')
trustee = client.Client(
auth_url='http://192.168.122.2:5000/v3',
username='admin',
password='openstack',
project_name='admin',
user_domain_name='Default',
project_domain_name='Default')
trustor.trusts.create(
trustor_user=trustor.user_id,
trustee_user=trustee.user_id,
project=trustor.project_id,
role_names=['Member'],
impersonation=True,
expires_at=None)
Trust deleted_at=None, expires_at=None,
id=ac0d8f3b9e7443c2bdb0f855c2a3b9b5, impersonation=True, links={u'self':
u'http://192.168.122.2:35357/v3/OS-TRUST/trusts/
ac0d8f3b9e7443c2bdb0f855c2a3b9b5'},
project_id=416290f342e04a34acccafe79bb399c7, redelegation_count=0,
remaining_uses=None, roles=[{u'id': u'433c86b705ef4656b90514ea5401469e',
u'links': {u'self':
u'http://192.168.122.2:35357/v3/roles/
433c86b705ef4656b90514ea5401469e'}, u'name':
u'Member'}], roles_links={u'self':
u'http://192.168.122.2:35357/v3/OS-TRUST/trusts/
ac0d8f3b9e7443c2bdb0f855c2a3b9b5/roles',
u'next': None, u'previous': None},
trustee_user_id=cf45da134c76460e89b5837e07cc4b82,
trustor_user_id=863b972dbbfd44b7bbde1b988e2b5098
the trust is created with no issues.
next, i try to create a Client using a Session and a Password auth
plugin object.
from keystoneclient.auth.identity import v3
from keystoneclient import session
sess = session.Session()
trustor_auth = v3.Password(
auth_url='http://192.168.122.2:5000/v3',
username='demo',
password='openstack',
project_name='demo',
user_domain_name='Default',
project_domain_name='Default')
trustee_auth = v3.Password(
auth_url='http://192.168.122.2:5000/v3',
username='admin',
password='openstack',
project_name='admin',
user_domain_name='Default',
project_domain_name='Default')
trustor = client.Client(session=sess, auth=trustor_auth)
trustee = client.Client(session=sess, auth=trustee_auth)
trustor.trusts.create(
trustor_user=trustor.user_id,
trustee_user=trustee.user_id,
project=trustor.project_id,
role_names=['Member'],
impersonation=True,
expires_at=None)
Traceback (most recent call last):
File stdin, line 1, in module
File
/home/mike/.venvs/openstack/lib/python2.7/site-packages/
keystoneclient/v3/contrib/trusts.py,
line 76, in create
**kwargs)
File
/home/mike/.venvs/openstack/lib/python2.7/site-packages/
keystoneclient/base.py,
line 73, in func
return f(*args, **new_kwargs)
File
/home/mike/.venvs/openstack/lib/python2.7/site-packages/
keystoneclient/base.py,
line 333, in create
self.key)
File
/home/mike/.venvs/openstack/lib/python2.7/site-packages/
keystoneclient/base.py,
line 151, in _create
return self._post(url, body, response_key, return_raw, **kwargs)
File
/home/mike/.venvs/openstack/lib/python2.7/site-packages/
keystoneclient/base.py,
line 165, in _post
Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients
On 08/05/2015 02:34 AM, Steve Martinelli wrote: I think this is happening because the last session created was based off of trustee_auth. Try creating 2 sessions, one for each user (trustor and trustee). Maybe Jamie will chime in. thanks for the reply Steve, i will give that a try. my understanding was that we could recycle the Session objects and just apply a new auth each time they are used. mike __ 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] policy issues when generating trusts with different clients
On 08/05/2015 02:34 AM, Steve Martinelli wrote: I think this is happening because the last session created was based off of trustee_auth. Try creating 2 sessions, one for each user (trustor and trustee). Maybe Jamie will chime in. just as a followup, i tried creating new Session objects for each client and i still get permission errors. i'm going to dig into the trust permission validation stuff a little. mike __ 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] policy issues when generating trusts with different clients
Hey Mike, I think it could be one of the hacks that are in place to try and keep compatibility with the old and new way of using the client is returning the wrong thing. Compare the output of trustor.user_id and trustor_auth.get_user_id(sess). For me trustor.user_id is None which will make sense why you'd get permission errors. Whether this is a bug in keystoneclient is debatable because we had to keep compatibility with the old options just not update them for the new paths, the ambiguity is certainly bad. The command that works for me is: trustor.trusts.create( trustor_user=trustor_auth.get_user_id(sess), trustee_user=trustee_auth.get_user_id(sess), project=trustor_auth.get_project_id(sess), role_names=['Member'], impersonation=True, expires_at=None) We're working on a keystoneclient 2.0 that will remove all that old code. Let me know if that fixes it for you. jamie - Original Message - From: michael mccune m...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, August 5, 2015 11:37:10 PM Subject: Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients On 08/05/2015 02:34 AM, Steve Martinelli wrote: I think this is happening because the last session created was based off of trustee_auth. Try creating 2 sessions, one for each user (trustor and trustee). Maybe Jamie will chime in. just as a followup, i tried creating new Session objects for each client and i still get permission errors. i'm going to dig into the trust permission validation stuff a little. mike __ 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
