Open Stack

Domains are not equivalent to tenants.  Currently there is no domain
equivalent in keystone.  That is my understanding.
On Aug 14, 2012 9:15 PM, "Naveen Joy (najoy)" <najoy at cisco.com> wrote:

>  I deeply desire tenant-uniqueness for usernames because it’s the natural
> way in which identity information is organized in a multi-tenant database,
> for instance LDAP uses DN\username or Domain\username convention and
> prevents name conflicts between tenants .  Can you elaborate on what the
> impact is to the NSS capacity referred below?.****
>
> ** **
>
> Cheers,****
>
> Naveen****
>
> ** **
>
> *From:* Matt Joyce [mailto:matt.joyce at cloudscaling.com]
> *Sent:* Tuesday, August 14, 2012 5:13 PM
> *To:* OpenStack Development Mailing List
> *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.FjFy7VMCkHKcWHJkXVkHUgtF.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****
>
> ** **
>
> _______________________________________________
> 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/20120814/ef3ef51c/attachment-0001.html>