[openstack-dev] [Keystone] Domain check in UserGroupMembership

Henry Nash henryn at linux.vnet.ibm.com
Thu Mar 21 18:29:43 UTC 2013


Hi Ronak,

So the domain container allows of uniqueness of user, group and project NAME to be within a domain only (i.e. so you can have a project called "Test" in two different domains, and they'll be different).  The user, group and project IDs, however, remain globally unique.  

By design, there is nothing in the api to prevent a user in one domain from having a role on a project in another domain.  I think that this will be an uncommon case for regular users, but might be common for classes of administrator, for example.

Henry


On 21 Mar 2013, at 18:01, Ronak Shah wrote:

> Hi,
> I was trying to make sense of the new keystone models looking at the code @ https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py
> 
> I liked the fact that we have a notion of domains as a global container for user, group and projects.
> I believe since its added as a foreignkey to all these tables, we are ensuring uniqueness of user, group and projects per domain.
> 
> On the same line, I think we are missing a check on the user-group, user-project relationship also to be unique per domain. Is this a bug or implementation? If implementation, why?
> 
> 
>     def add_user_to_group(self, user_id, group_id):
> 
>         session = self.get_session()
> 
>         self.get_group(group_id)
> 
>         self.get_user(user_id)
> 
>         query = session.query(UserGroupMembership)
> 
>         query = query.filter_by(user_id=user_id)
> 
>         query = query.filter_by(group_id=group_id)
> 
>         rv = query.first()
> 
>         if rv:
> 
>             return
> 
> 
>         with session.begin():
> 
>             session.add(UserGroupMembership(user_id=user_id,
> 
>                                             group_id=group_id))
> 
>             session.flush()
> 
> 
> 
> Above code adds user to group without checking for the common domain. 
> This allow User A in Domain A associated with Group B in Domain B?
> 
> Ideally User A shouldnt be doing anything in Domain B. Isnt it?
> 
> 
> Thanks,
> 
> Ronak
> 
> 
> 
> _______________________________________________
> 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/20130321/7a2eef98/attachment.html>


More information about the OpenStack-dev mailing list