Open Stack

I got it. We need to create something like domain-wide backend
configuration. Domain can contain several tenants and users and should be
explicitly specified in authentication data.
The only problem I see here is security. If I have a cloud and provide
access to it to some company, they are free to create any tenant and user
they want, so they can gain access to part of cloud that wasn't dedicated to
them.
This can be solved either by tweaking services to handle user, roles and
tenants on per-domain basis or by adding (maybe in @-style) domain to all
this names in all requests that are expected from cloud services (like
validate_token).

Kind regards, Yuriy.

On Fri, Jul 15, 2011 at 23:11, andi abes <andi.abes at gmail.com> wrote:

> Just to clarify - yuriy, what you're describing is very reasonable for an
> enterprise system, where you definitely strive to achieve centralized
> authentication. I however believe that model is too restrictive for a cloud
> service provider. These two worlds are somewhat different.
>
> On Jul 15, 2011, at 15:07, andi abes <andi.abes at gmail.com> wrote:
>
> I guess sfdc disagrees with you - they allow e.g Dell to use a single sign
> on to authenticate to their services - as a @dell user, you can login with
> the same email/password to internal resources as well as sfdc ones. ( in
> case it's not obvious - you also update your password in one location - the
> Dell AD directory)
>
> On Jul 15, 2011, at 14:14, Yuriy Taraday < <yorik.sar at gmail.com>
> yorik.sar at gmail.com> wrote:
>
> Currently there is a basic skeleton for only one backend (identity
> store) configuration per Keystone instance. It can be either DB or LDAP (the
> latter is almost done).
> May be in future we should be somehow able to specify not only tenants but
> also an backend for each authentication request.
> But I cannot imagine a real use case for that. All identities should be
> stored in one place. I doubt that it'll be useful to keep different users
> and/or tenants (or roles or whatever) in different stores. There usually is
> one single central repository, DB, LDAP or may be some billing system. If we
> have two isolated systems, we should consider using two separate auth
> services.
>
> Kind regards, Yuriy.
>
>
> On Fri, Jul 15, 2011 at 21:40, andi abes < <andi.abes at gmail.com><andi.abes at gmail.com>
> andi.abes at gmail.com> wrote:
>
>> 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 at gmail.com><yorik.sar at gmail.com>
>> yorik.sar at gmail.com> 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 at hp.com><liem_m_nguyen at hp.com>
>>> liem_m_nguyen at hp.com> 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= <http://hp.com><http://hp.com>
>>>> hp.com@ <http://lists.launchpad.net> <http://lists.launchpad.net>
>>>> lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=<http://hp.com><http://hp.com>
>>>> hp.com@ <http://lists.launchpad.net> <http://lists.launchpad.net>
>>>> lists.launchpad.net] *On Behalf Of *Ziad Sawalha
>>>> *Sent:* Thursday, July 14, 2011 12:22 PM
>>>>
>>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>>> <openstack at lists.launchpad.net> <openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net
>>>> *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 at hp.com><jason.rouault at hp.com>
>>>> jason.rouault at hp.com>
>>>> *Date: *Thu, 14 Jul 2011 16:25:22 +0000
>>>> *To: *Ziad Sawalha < <ziad.sawalha at rackspace.com><ziad.sawalha at rackspace.com>
>>>> ziad.sawalha at rackspace.com>, Yuriy Taraday < <yorik.sar at gmail.com><yorik.sar at gmail.com>
>>>> yorik.sar at gmail.com>, " <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net" < <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net>
>>>> *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 [ <ziad.sawalha at rackspace.com><ziad.sawalha at rackspace.com>
>>>> mailto:ziad.sawalha at rackspace.com <ziad.sawalha at rackspace.com>]
>>>> *Sent:* Wednesday, July 13, 2011 10:35 PM
>>>> *To:* Rouault, Jason (Cloud Services); Yuriy Taraday;
>>>> <openstack at lists.launchpad.net> <openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net
>>>> *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 at hp.com><jason.rouault at hp.com>
>>>> jason.rouault at hp.com>
>>>> *Date: *Wed, 13 Jul 2011 13:18:44 +0000
>>>> *To: *Ziad Sawalha < <ziad.sawalha at rackspace.com><ziad.sawalha at rackspace.com>
>>>> ziad.sawalha at rackspace.com>, Yuriy Taraday < <yorik.sar at gmail.com><yorik.sar at gmail.com>
>>>> yorik.sar at gmail.com>, " <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net" < <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net>
>>>> *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 at lists.launchpad.net><openstack-bounces+jason.rouault=hp.com at lists.launchpad.net>
>>>> openstack-bounces+jason.rouault=hp.com at lists.launchpad.net [<openstack-bounces+jason.rouault=hp.com at lists.launchpad.net><openstack-bounces+jason.rouault=hp.com at lists.launchpad.net>
>>>> mailto:openstack-bounces+jason.rouault=hp.com at lists.launchpad.net<openstack-bounces+jason.rouault=hp.com at lists.launchpad.net>]
>>>> *On Behalf Of *Ziad Sawalha
>>>> *Sent:* Tuesday, July 12, 2011 10:09 PM
>>>> *To:* Yuriy Taraday; <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net
>>>> *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 at gmail.com> <yorik.sar at gmail.com>
>>>> yorik.sar at gmail.com>
>>>> *Date: *Tue, 28 Jun 2011 16:59:08 +0400
>>>> *To: *< <openstack at lists.launchpad.net> <openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net>
>>>> *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> <https://launchpad.net/~openstack>
>>>> https://launchpad.net/~openstack Post to :
>>>> <openstack at lists.launchpad.net> <openstack at lists.launchpad.net>
>>>> openstack at lists.launchpad.net Unsubscribe :
>>>> <https://launchpad.net/~openstack> <https://launchpad.net/~openstack>
>>>> https://launchpad.net/~openstack More help :
>>>> <https://help.launchpad.net/ListHelp><https://help.launchpad.net/ListHelp>
>>>> 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><https://launchpad.net/~openstack>
>>> https://launchpad.net/~openstack
>>> Post to     : <openstack at lists.launchpad.net><openstack at lists.launchpad.net>
>>> openstack at lists.launchpad.net
>>> Unsubscribe : <https://launchpad.net/~openstack><https://launchpad.net/~openstack>
>>> https://launchpad.net/~openstack
>>> More help   : <https://help.launchpad.net/ListHelp><https://help.launchpad.net/ListHelp>
>>> https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110716/09b40e37/attachment.html>