Open Stack

On Jun 8, 2012, at 6:47 PM, "Nguyen, Liem Manh" <liem_m_nguyen at hp.com> wrote:

> Hi Joe/Dolph,
>  
> I have a few questions on the v3 API’s create_user (sorry the comments section in the Google docs is getting pretty cluttered now):
>  
> (POST) /users ==> create_user
> {
> " tenant_id": ...
> "name": ...
> "password": ...
> "enabled": ...
> "email": ...
> "description": ...
> }
>  
> 1.       Does this tenant_id option establish the default tenancy of the created user?

Yes.

> 2.       If it does, is this default tenancy immutable or mutable?  If it is mutable, who (what role) can change it and via what API?

Should be mutable by admins, via the admin API, as it's just a regular attribute of the user and the keystone "admin" concept currently applies to the entire deployment.

> 3.       What is the intended purpose of a user’s default tenancy?  Is the default tenancy association intended to link a user to a given domain (rather than the normal user-tenant role association)?

"Auto-scoping" the user's context, when a tenant is not explicitly specified during auth.

I can't fairly answer the second question because the idea of domains wasn't around at the time. However, if you replace the term "domain" with "tenant", I'd say yes.

>  
> The reason I am asking this is that I would like to know what level of isolation (if any) we can establish for users that are homed to different domains…  So, for example, an isolation would be that a user A with a default tenancy in domain X may not be modified or deleted by a domain-admin in domain Y, even when user A has tenant membership in domain Y.

I think that's an issue best solved per-deployment by robust RBAC, rather than being hardcoded either way.

>  
> Thanks,
> Liem
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120608/cc77ba8f/attachment.html>