openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

+1

The second "way to accomplish this" is exactly what keystone currently supports (explicit role grants), which didn't change between diablo and essex at all.

The first method (using global unscopedness) was dropped because its just as confusing as you describe it.

-Dolph Mathews

On May 10, 2012, at 2:35 AM, Joseph Heck <heckj@xxxxxxx> wrote:

> Guang,
> 
> I think you need to re-read the code. The association between a user and tenant is what the role represents, and its inaccurate to assert that a user is aligned only with a single tenant ever, that is not the case. 
> 
> A role is no longer global, specifically to avoid the tremendous confusion and inaccuracy of implementation about how to apply a role that relates a tenant and user along with a potential "global" role concept that was in the earliest implementations of Keystone. The current implementation is simpler and far more specific and clear in it's implementation.
> 
> -joe
> 
> On May 9, 2012, at 10:22 PM, Yee, Guang wrote:
>> I think this use case underscores one of the key differences between the fat Keystone (Diablo - E3) and KSL (Essex final).  In fat Keystone, users and tenants are loosely coupled. They are bind together by role assignments. In KSL, users and tenants are tightly coupled, and IMHO very inflexible. Maybe the following example would further clarify this …
>>  
>> Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, roles Commissioner and Minority Owner, and service MLB. And you want Bud Selid to have the Commissioner role for Dodgers, Giants, and Brewers, but Minority Owner role for Brewers only.
>>  
>> In fat Keystone, there a couple of ways you can accomplish this.
>>  
>> 1)      Make Commissioner a “global role” (unscoped) and assign it to user Bud Selid. Assign the Minority Owner role to Bud Selid for tenant Brewers by creating a role reference. When Bud Selid tries to access MLB with his unscoped token, MLB will get his Commissioner role back from Keystone. When Bud Selid tries to access MLB with his token scoped to Brewers, MLB will get both his Commissioner and Minority Owner roles back from Keystone. When Bud Selid tries to acess MLB with his token scoped to Giants or Dodgers, MLB will only get his Commissioner role back from Keystone.
>> 2)      Assign the Commissioner role to Bud Selid to tenants Giants, Dodgers, and Brewers individually by creating the respective role references. Assign the Minority Owner role to Bud Selid for tenant Brewers by creating another role reference. In this scenario, Bud Selid will always need a scoped token to access MLB.
>>  
>> In KSL, there really aren’t any effective ways to accomplish the same thing. Global roles are no longer supported.  A given user must assign to exactly one tenant. I suppose you can have Bud Selid under the “Default Tenant”, and assign both Commissioner and Minority Owner roles to him. But there are two major side effects.
>>  
>> 1)      Bud Selid must access MLB with the token scoped to the “Default Tenant” in order for MLB to recognize him as Commissioner. Which means he IS ALSO the Minority Owner for Dodgers, Giants, and Brewers. J
>> 2)      If Bud Selid tries to access MLB with the token scoped to either Giants, Dodgers, or Brewers, his a NOBODY. J
>>  
>> The upcoming Domains blueprint (to be implemented for Folsom), which offers true multitenancy, should support these types of use cases.
>>  
>> https://blueprints.launchpad.net/keystone/+spec/keystone-domains
>>  
>> With Domains, you can create a MLB domain with tenants Dodgers, Giants, and Brewers. And have Bud Selid under the MLB domain. Notice that users will no longer be assigned to tenants. They will be under a domain. Create roles Commissioner and Minority Owner in the MLB domain. Assign the Commissioner role to Bud Selid, and the Minority Owner role scoped to Brewers. Suppose you have another domain NFL, Bud Selid will not be able to access any tenants in the NFL domain, unless the NFL domain administrator explicitly assign NFL roles to Bud Selid.
>>  
>>  
>> Guang
>>  
>>  
>>  
>>  
>> From: openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dolph Mathews
>> Sent: Wednesday, May 09, 2012 4:34 PM
>> To: Joshua Harlow
>> Cc: openstack
>> Subject: Re: [Openstack] Keystone client, user belongs to many tenants?
>>  
>> The user create command is actually creating discrete users, each with a "default tenant" reference.
>>  
>> While that's fine for a lot of simple use cases, it doesn't directly support a user accessing multiple tenants at all.
>>  
>> Instead, create a role, and grant that role to a user-tenant pair, creating an explicit relationship between the two. Using default tenants is optional with this method, but will affect how users must auth.
>> 
>> -Dolph Mathews
>> 
>> On May 9, 2012, at 3:46 PM, Joshua Harlow <harlowja@xxxxxxxxxxxxx> wrote:
>> 
>> A question,
>> 
>> I am using anvil to setup the keystone roles/users/tenants.
>> 
>> It seems like the python keystone  client has the following command:
>> 
>> client.users.create
>> 
>> Which seems to take in the following:
>> 
>> create(self, name, password, email, tenant_id=None, enabled=True):
>> 
>> I would assume a user name can be used in multiple tenants but when I am trying to create a user that spans tenants and it seems like it borks.
>> 
>> ClientException: Conflict occurred attempting to store user. (IntegrityError) (1062, "Duplicate entry 'admin' for key 'name'") 'INSERT INTO user (id, name, extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin', '{"password": "$6$rounds=40000$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/", "enabled": true, "email": "admin@xxxxxxxxxxx", "tenantId": "d1506184877a449a91fc6adcb553ad97"}') (HTTP 409)
>> 
>> Is this supposed to happen? Is the client supposed to send back this much info also (hashed password??) :-P
>> 
>> Any ideas?
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>