Open Stack

I think that there is a problem with simply using https://SWIFT/AUTH_
{PROJECT_ID} instead of the current  https://SWIFT/AUTH_{TENANT_ID} since 
it will loose the proper level in the hierarchy. We need something that 
will represent the hosted enterprises and this is the goal of domains. 
Project are more fine-grained and can represent departments or projects. 
For example, following the description of Henry if two different 
enterprises with use the project name "Test" both with map to 
https://SWIFT/AUTH_Test. 

I think that we need to have both the domain id and the project id in the 
URL/account name. For example as https://SWIFT/AUTH_
{DOMAIN_ID}_{PROJECT_ID} or as https://SWIFT/{DOMAIN_ID}_{PROJECT_ID}. In 
the second option we may try using the existing reseller prefix mechanism 
to simplify the implementation. Having the doman_id in the account 
name/URL is important to isolate the accounts that belong to different 
domains and remove the requirements for the global uniqueness of project 
names. 

Best Regards,
Alex. 



From:   Chuck Thier <cthier at gmail.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   08/01/2013 09:38 PM
Subject:        Re: [openstack-dev] [swift] [keystone] Keystone v3 API 
domains in      Swift



Hi Henry,

>From a swift perspective, I think we are fine there, as we do not use
the user name or project name anywhere.  At the moment, I'm thinking
that we can do auth in a similar way as we did with v2.0 api.  An
"account" in swift is still tied to the project_id (which used to be
tennant_id), which is in the storage url like:
https://SWIFT/AUTH_{PROJECT_ID}.  Keystone middleware in swift
validates that the given token has permission for the given Project
ID.

>From this point of view domains are an abstract concept in keystone
only, and wouldn't mean anything directly in swift.

Please let me know if any of my assumptions are incorrect.

Thanks,

--
Chuck

On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <henryn at linux.vnet.ibm.com> 
wrote:
> Chuck,
>
> So user_id and project_id are always globally unique - so we are safe 
there.  The problem is when you specify user name or project name in the 
cases when we have to handle enterprises being represented by a domain and 
they insist that their name attributes (e.g. user names, project names 
etc.) be private to that domain (e.g. "what do you mean I can't call my 
project "Test" because some other customer in another domain got there 
first!?!").  See the following blueprint which introduces this ability as 
optional for domains: https://review.openstack.org/#/c/18805/
>
> For such domains, we cannot assume that user_name or project_name (or 
tenant_name as it used to be called) are globally unique.  "Domain_name 
(or id) plus user_name" as well as  "Domain_name (or id) plus 
project_name" will be unique however.
>
> Henry
> On 8 Jan 2013, at 19:05, Chuck Thier wrote:
>
>> Yeah, I was hoping for more clarity, as it would help to figure out
>> how to best map the concepts in swift.  A couple of quick questions
>> come to mind.  When a request is validated, is the domain required, or
>> is a user_id and project_id sufficient?  Is the concept of a domain
>> useful in the context of swift?
>>
>> --
>> Chuck
>>
>> On Tue, Jan 8, 2013 at 11:37 AM, heckj <heckj at mac.com> wrote:
>>> The best is probably 
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md
, but it's a bit light on use-cases around the concepts I'm afraid.
>>>
>>> -joe
>>>
>>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <cthier at gmail.com> wrote:
>>>> Is there documentation anywhere that defines all of these, and the 
use
>>>> cases?  That would help us figure out how to map these concepts to
>>>> swift.
>>>>
>>>> --
>>>> Chuck
>>>>
>>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews 
<dolph.mathews at gmail.com> wrote:
>>>>> I think it would be practical to expose the authenticated user's 
DOMAIN_ID
>>>>> and DOMAIN_NAME into the request environment for the underlying 
service /
>>>>> middleware to consume, as we do today with TENANT_ID / TENANT_NAME 
(soon to
>>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).
>>>>>
>>>>>
>>>>> -Dolph
>>>>>
>>>>>
>>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg
>>>>> <SHULMANA at il.ibm.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As most of you know, Keystone v3 API will introduce the notions of
>>>>>> "domains" and "projects" which will replace the existing notion of 
tenants.
>>>>>> It is important to allow using the same concepts in Swift. Since 
different
>>>>>> domains may represent different companies, it is important to allow
>>>>>> reflecting the Keystone "domain name" in the Swift "account name", 
providing
>>>>>> an option to isolate the requests of different domains. Are there 
existing
>>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would like 
to start
>>>>>> discussing the potential solutions.
>>>>>>
>>>>>> Thank you all,
>>>>>> Alex.
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Alexandra Shulman-Peleg, PhD
>>>>>> Storage Research, Cloud Platforms Dept.
>>>>>> IBM Haifa Research Lab
>>>>>> Tel: +972-3-7689530 | Fax: +972-3-7689545
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130108/a83f6217/attachment.html>