<font size=2 face="sans-serif">I think that there is a problem with simply
using </font><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</font></tt></a><tt><font size=2>{PROJECT_ID}</font></tt><font size=2 face="sans-serif">
instead of the current  </font><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</font></tt></a><tt><font size=2>{TENANT_ID}
</font></tt><font size=2 face="sans-serif">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 </font><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</font></tt></a><tt><font size=2>Test.
</font></tt>
<br>
<br><font size=2 face="sans-serif">I think that we need to have both the
domain id and the project id in the URL/account name. For example as </font><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</font></tt></a><tt><font size=2>{DOMAIN_ID}_{PROJECT_ID}
or as </font></tt><a href=https://swift/><tt><font size=2>https://SWIFT/</font></tt></a><tt><font size=2>{DOMAIN_ID}_{PROJECT_ID}.
</font></tt><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">Best Regards,</font>
<br><font size=2 face="sans-serif">Alex. </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Chuck Thier <cthier@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">08/01/2013 09:38 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[swift] [keystone] Keystone v3 API domains in        Swift</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi Henry,<br>
<br>
>From a swift perspective, I think we are fine there, as we do not use<br>
the user name or project name anywhere.  At the moment, I'm thinking<br>
that we can do auth in a similar way as we did with v2.0 api.  An<br>
"account" in swift is still tied to the project_id (which used
to be<br>
tennant_id), which is in the storage url like:<br>
</font></tt><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</font></tt></a><tt><font size=2>{PROJECT_ID}.
 Keystone middleware in swift<br>
validates that the given token has permission for the given Project<br>
ID.<br>
<br>
>From this point of view domains are an abstract concept in keystone<br>
only, and wouldn't mean anything directly in swift.<br>
<br>
Please let me know if any of my assumptions are incorrect.<br>
<br>
Thanks,<br>
<br>
--<br>
Chuck<br>
<br>
On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <henryn@linux.vnet.ibm.com>
wrote:<br>
> Chuck,<br>
><br>
> 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: </font></tt><a href=https://review.openstack.org/#/c/18805/><tt><font size=2>https://review.openstack.org/#/c/18805/</font></tt></a><tt><font size=2><br>
><br>
> 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.<br>
><br>
> Henry<br>
> On 8 Jan 2013, at 19:05, Chuck Thier wrote:<br>
><br>
>> Yeah, I was hoping for more clarity, as it would help to figure
out<br>
>> how to best map the concepts in swift.  A couple of quick
questions<br>
>> come to mind.  When a request is validated, is the domain
required, or<br>
>> is a user_id and project_id sufficient?  Is the concept of
a domain<br>
>> useful in the context of swift?<br>
>><br>
>> --<br>
>> Chuck<br>
>><br>
>> On Tue, Jan 8, 2013 at 11:37 AM, heckj <heckj@mac.com> wrote:<br>
>>> The best is probably </font></tt><a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md"><tt><font size=2>https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md</font></tt></a><tt><font size=2>,
but it's a bit light on use-cases around the concepts I'm afraid.<br>
>>><br>
>>> -joe<br>
>>><br>
>>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <cthier@gmail.com>
wrote:<br>
>>>> Is there documentation anywhere that defines all of these,
and the use<br>
>>>> cases?  That would help us figure out how to map
these concepts to<br>
>>>> swift.<br>
>>>><br>
>>>> --<br>
>>>> Chuck<br>
>>>><br>
>>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews <dolph.mathews@gmail.com>
wrote:<br>
>>>>> I think it would be practical to expose the authenticated
user's DOMAIN_ID<br>
>>>>> and DOMAIN_NAME into the request environment for the
underlying service /<br>
>>>>> middleware to consume, as we do today with TENANT_ID
/ TENANT_NAME (soon to<br>
>>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).<br>
>>>>><br>
>>>>><br>
>>>>> -Dolph<br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg<br>
>>>>> <SHULMANA@il.ibm.com> wrote:<br>
>>>>>><br>
>>>>>> Hi,<br>
>>>>>><br>
>>>>>> As most of you know, Keystone v3 API will introduce
the notions of<br>
>>>>>> "domains" and "projects" which
will replace the existing notion of tenants.<br>
>>>>>> It is important to allow using the same concepts
in Swift. Since different<br>
>>>>>> domains may represent different companies, it
is important to allow<br>
>>>>>> reflecting the Keystone "domain name"
in the Swift "account name", providing<br>
>>>>>> an option to isolate the requests of different
domains. Are there existing<br>
>>>>>> plans of adjusting Swift to Keystone v3 API? If
not, I would like to start<br>
>>>>>> discussing the potential solutions.<br>
>>>>>><br>
>>>>>> Thank you all,<br>
>>>>>> Alex.<br>
>>>>>><br>
>>>>>><br>
>>>>>> ----------------------------------------------------------<br>
>>>>>> Alexandra Shulman-Peleg, PhD<br>
>>>>>> Storage Research, Cloud Platforms Dept.<br>
>>>>>> IBM Haifa Research Lab<br>
>>>>>> Tel: +972-3-7689530 | Fax: +972-3-7689545<br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> OpenStack-dev@lists.openstack.org<br>
>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> OpenStack-dev@lists.openstack.org<br>
>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>