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 <[email protected]> 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 <[email protected]>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:* [email protected][mailto: >> [email protected]] *On Behalf Of >> *Ziad Sawalha >> *Sent:* Thursday, July 14, 2011 12:22 PM >> >> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday; >> [email protected] >> *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)" <[email protected]> >> *Date: *Thu, 14 Jul 2011 16:25:22 +0000 >> *To: *Ziad Sawalha <[email protected]>, Yuriy Taraday < >> [email protected]>, "[email protected]" < >> [email protected]> >> *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:[email protected]<[email protected]>] >> >> *Sent:* Wednesday, July 13, 2011 10:35 PM >> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday; >> [email protected] >> *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)" <[email protected]> >> *Date: *Wed, 13 Jul 2011 13:18:44 +0000 >> *To: *Ziad Sawalha <[email protected]>, Yuriy Taraday < >> [email protected]>, "[email protected]" < >> [email protected]> >> *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:* [email protected] [ >> mailto:[email protected]<[email protected]>] >> *On Behalf Of *Ziad Sawalha >> *Sent:* Tuesday, July 12, 2011 10:09 PM >> *To:* Yuriy Taraday; [email protected] >> *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 <[email protected]> >> *Date: *Tue, 28 Jun 2011 16:59:08 +0400 >> *To: *<[email protected]> >> *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 : >> [email protected] : >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
