← Back to team overview

openstack team mailing list archive

Re: Keystone tenants vs. Nova projects

 

Yuriy,

a  use-case scenario for keystone would be a service provider servicing
 large customers with  their own  authentication infrastructure (e.g. LDAP/
AD etc). Obviously, different tenants  have different instances. To
authenticate a user, the correct authentication back end must be selected.

In your model, how would a service provide be able to allow delegated
authentication to different customers?


On Fri, Jul 15, 2011 at 1:37 AM, Yuriy Taraday <yorik.sar@xxxxxxxxx> wrote:

> I think, there should not be such thing as default tenant.
> If user does not specify tenant in authentication data, ones token should
> not be bound to any tenant, and user should have access to resources based
> on global role assignments.
> If user specify tenant, one should be either explicitly bound to tenant
> (probably through UserRoleAssignment model, but it is not the best way) or
> in some global role. Then one will have access to resources based on global
> role assignments and tenant role assignments.
> I'm not sure whether users should be added to a tenant and then to roles in
> this tenant or we should remove totally direct link between user and tenant,
> so that user is in tenant if and only if one is in any role in this tenant.
>
> Kind regards, Yuriy.
>
>
> On Fri, Jul 15, 2011 at 00:07, Nguyen, Liem Manh <liem_m_nguyen@xxxxxx>wrote:
>
>>  When one creates a user, should a user always have a tenant associated
>> with her?  If that’s the case, then the “default” tenant is the tenant that
>> the user is associated with at creation time?  Sorry for responding to the
>> question with another question, but it is unclear for me from looking at the
>> model (there is no non-null constraint on the tenant_id fk on the user
>> table).****
>>
>> ** **
>>
>> Thanks,****
>>
>> Liem****
>>
>> ** **
>>
>> *From:* openstack-bounces+liem_m_nguyen=hp.com@xxxxxxxxxxxxxxxxxxx[mailto:
>> openstack-bounces+liem_m_nguyen=hp.com@xxxxxxxxxxxxxxxxxxx] *On Behalf Of
>> *Ziad Sawalha
>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>
>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>> openstack@xxxxxxxxxxxxxxxxxxx
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects****
>>
>>  ** **
>>
>> In the example I gave below they are not members of any group and have no
>> roles assigned to them. Should they still be authenticated?****
>>
>> ** **
>>
>> *From: *"Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx>
>> *Date: *Thu, 14 Jul 2011 16:25:22 +0000
>> *To: *Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>, Yuriy Taraday <
>> yorik.sar@xxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx" <
>> openstack@xxxxxxxxxxxxxxxxxxx>
>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects****
>>
>> ** **
>>
>> A user can specify a tenantID at the time of authentication.  If no
>> tenantID is specified during authentication, then I would expect the
>> ‘default’ tenant for the user would apply.  The capabilities of User1 on
>> TenantA (in this case the default tenant for the user) would be determined
>> by their role and group assignments within the context of TenantA.  ****
>>
>>  ****
>>
>> Jason****
>>
>>  ****
>>
>> *From:* Ziad Sawalha [mailto:ziad.sawalha@xxxxxxxxxxxxx<ziad.sawalha@xxxxxxxxxxxxx>]
>>
>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>> openstack@xxxxxxxxxxxxxxxxxxx
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects****
>>
>>  ****
>>
>> What if:****
>>
>>  ****
>>
>> -          User1 has TenantA as her default tenant****
>>
>>  ****
>>
>> Should the service authenticate the user against TenantA? And if so, why?
>> What does the 'default tenant' grant User1 on TenantA? It's some nebulous,
>>  implied role…****
>>
>>  ****
>>
>>  ****
>>
>>  ****
>>
>> *From: *"Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx>
>> *Date: *Wed, 13 Jul 2011 13:18:44 +0000
>> *To: *Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>, Yuriy Taraday <
>> yorik.sar@xxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx" <
>> openstack@xxxxxxxxxxxxxxxxxxx>
>> *Subject: *RE: [Openstack] Keystone tenants vs. Nova projects****
>>
>>  ****
>>
>> If a user is bound to their default tenant, why wouldn’t any role
>> assignments for that user in their default tenant apply?****
>>
>>  ****
>>
>>  ****
>>
>> User1 authenticates specifying TenantB, this binds User1 into the context
>> of TenantB.  In subsequent web service requests using the token received
>> after authentication, the Auth component filter would decorate the headers
>> with RoleY.****
>>
>> If User1 authenticates specifying TenantA, or specifying no Tenant,  this
>> binds User1 into the context of TenantA.  The headers would then be
>> decorated with RoleX.****
>>
>>  ****
>>
>> Jason****
>>
>>  ****
>>
>> *From:* openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx [
>> mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx<openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx>]
>> *On Behalf Of *Ziad Sawalha
>> *Sent:* Tuesday, July 12, 2011 10:09 PM
>> *To:* Yuriy Taraday; openstack@xxxxxxxxxxxxxxxxxxx
>> *Subject:* Re: [Openstack] Keystone tenants vs. Nova projects****
>>
>>  ****
>>
>> Our goal is to support Nova use cases right now. You can provide access to
>> multiple tenants using a role assignment (assigning a user a role on a
>> specific tenant effectively binds them to that tenant).****
>>
>>  ****
>>
>> However, this raises the issue of what the 'implied' role of a user is
>> when they are bound to their *default* tenant. So we're considering how
>> to alter the model to clean that up. No great solution yet. Any suggestions
>> are welcome….****
>>
>>  ****
>>
>> Ziad****
>>
>>  ****
>>
>> *From: *Yuriy Taraday <yorik.sar@xxxxxxxxx>
>> *Date: *Tue, 28 Jun 2011 16:59:08 +0400
>> *To: *<openstack@xxxxxxxxxxxxxxxxxxx>
>> *Subject: *[Openstack] Keystone tenants vs. Nova projects****
>>
>>  ****
>>
>> Currently Keystone model assumes that user is bound to exactly one tenant.
>> It conflicts with the fact that in Nova user can have access to several
>> projects. ****
>>
>> Which way will it be?
>> ****
>>
>> Kind regards, Yuriy.****
>>
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netUnsubscribe :
>> https://launchpad.net/~openstack More help :
>> https://help.launchpad.net/ListHelp This email may include confidential
>> information. If you received it in error, please delete it.****
>>
>> This email may include confidential information. If you received it in
>> error, please delete it.****
>>
>> This email may include confidential information. If you received it in
>> error, please delete it.****
>>
>
> -- PASS THROUGH --
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References