Open Stack

In fact they are equivalent. LDAP domains  could use an organization name and a keystone tenant maps to an organization.

From: Matt Joyce [mailto:matt.joyce at cloudscaling.com]
Sent: Tuesday, August 14, 2012 9:31 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Keystone user creation question


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<mailto: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<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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20120815/ff13966f/attachment-0001.html>