On Jun 8, 2012, at 8:38 PM, Dolph Mathews wrote:
> On Jun 8, 2012, at 6:47 PM, "Nguyen, Liem Manh" <liem_m_ngu...@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)?
To be a little more explicit about the "default tenant" thing - it's used so
that the user can give a "username/password" pair to the POST to /token and get
a token scoped to a tenant without the user asserting which tenant it wishes to
use.
> "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.
I agree with Dolph - since domains don't segment users, only tenants - then the
choice is really driven by RBAC, which can be encapsulated in rules. None of
the API defined in the v1 draft currently even hints at what RBAC might be
wrapped around each of the calls, but all of those calls can and should be
wrapped as actions and defined in the policy.json file.
We do need to come up with a suggested default implementation - given that
users are not segmented into domains, what would you suggest?
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
