<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 <a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</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 </tt><a href=https://swift/><tt><font size=2>https://SWIFT/</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>

</tt><a href=https://swift/AUTH_><tt><font size=2>https://SWIFT/AUTH_</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>