Open Stack

The current domain blueprint has usernames globally unique.

Jason

From:  Matt Joyce <matt.joyce at cloudscaling.com>
Reply-To:  OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Date:  Tuesday, August 14, 2012 6:12 PM
To:  OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] Keystone user creation question

I deeply desire that we continue to require unique names across keystone.  I
do not like the idea of tenant specific or domain specific names.  It may
cost us down the road if we ever decide we want to provide NSS capacity
based off of keystone.

-Matt

On Tue, Aug 14, 2012 at 5:06 PM, Joseph Heck <heckj at me.com> wrote:
> Hey Naveen - 
> 
> Although the spec is currently for keeping the usernames unique globally,
> domains (part of the V3 API setup) will allow us to have a boundary/barrier
> for uniqueness if that's desired.
> 
> The quirk that is keeping it in place is generally *not* mandating that the
> end user - when authenticating - know the "project/tenant" name to which
> they're authenticating. If we allowed tenant-uniqueness for usernames, then in
> order to log in and guarantee uniqueness so we could authZ someone, we would
> need to know the tenant up front as well. Current systems (like logging in to
> the horizon dashboard) *do not* require that.
> 
> -joe
> 
> On Aug 14, 2012, at 4:55 PM, Naveen Joy (najoy) <najoy at cisco.com> wrote:
>> It¹s valid for the same username to exist across multiple tenants and should
>> be only unique for a  tenant. Keystone today is enforcing uniqueness for a
>> name  and prevents creation of the same user across tenants. Is there a plan
>> to use (tenantID, name) as a composite key instead of just the name?.
>>  
>> Conflict occurred attempting to store user. (IntegrityError) (1062,
>> "Duplicate entry 'admin' for key 'name'") 'INSERT INTO user (id, name, extra)
>> VALUES (%s, %s, %s)' ('697addf1c62a4eaea33d6c99076269d6', 'admin',
>> '{"password": 
>> "$6$rounds=40000$SGj4.DyRasD5jy7l$uZNGjWvUkgJkqrGb4B/4uXga.FjFy7VMCkHKcWHJkXV
>> kHUgtF.D1SDz9RwO3aazvGhyGUQK/isK3jwNprSpVD.", "enabled": true, "email": null,
>> "tenantId": "0f8423b5c8a74ffc91c0ccf1c7015aa3"}') (HTTP 409)
>>  
>> desc user;
>> +-------+-------------+------+-----+---------+-------+
>> | Field | Type        | Null | Key | Default | Extra |
>> +-------+-------------+------+-----+---------+-------+
>> | id    | varchar(64) | NO   | PRI | NULL    |       |
>> | name  | varchar(64) | NO   | UNI | NULL    |       |
>> | extra | text        | YES  |     | NULL    |       |
>> +-------+-------------+------+-----+---------+-------+
>> 3 rows in set (0.00 sec)
>>  
>>  
>> Cheers,
>> Naveen
>>  
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20120816/84f17e9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2298 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120816/84f17e9b/attachment-0001.bin>