<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yeah, I don’t see a need to add domain_id to Swift account either as project ID is globally unique. Since domain name/id are returned as part of token validation, you may be able to use them with Swift ACLs. I am sure Swift ACLs will need to be updated if and when we remove the globally uniqueness name requirement.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Guang<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dolph Mathews [mailto:dolph.mathews@gmail.com] <br><b>Sent:</b> Tuesday, January 08, 2013 2:38 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>TENANT_ID in v2 is exactly equal to PROJECT_ID in v3. ID's are guaranteed to be globally unique (implemented as service-defined UUID's) and are url-friendly.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Names in keystone are freeform, user-supplied unicode strings. They may not work in URL's without proper encoding and may collide in the future...<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>On that note, TENANT_NAME in v2 will become PROJECT_NAME in v3, however we're also talking about namespacing project names to the owning domain, so that two domains may have otherwise conflicting project names. Once we open up the namespace, we can't go back, so we're going about it very carefully. This may apply to user names, as well, but that's a subtly different conversation.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If we do make this change then you also need to identify the domain for a project name to be meaningful.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>ID's will still uniquely identify a project regardless of domain or deployment.<o:p></o:p></p></div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-Dolph<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Jan 8, 2013 at 2:11 PM, Alexandra Shulman-Peleg <<a href="mailto:SHULMANA@il.ibm.com" target="_blank">SHULMANA@il.ibm.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>I think that there is a problem with simply using </span><a href="https://swift/AUTH_" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/AUTH_</span></tt></a><tt><span style='font-size:10.0pt'>{PROJECT_ID}</span></tt><span style='font-family:"Arial","sans-serif"'> instead of the current </span><a href="https://swift/AUTH_" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/AUTH_</span></tt></a><tt><span style='font-size:10.0pt'>{TENANT_ID} </span></tt><span style='font-family:"Arial","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 </span><a href="https://swift/AUTH_" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/AUTH_</span></tt></a><tt><span style='font-size:10.0pt'>Test. </span></tt><br><br><span style='font-family:"Arial","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 </span><a href="https://swift/AUTH_" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/AUTH_</span></tt></a><tt><span style='font-size:10.0pt'>{DOMAIN_ID}_{PROJECT_ID} or as </span></tt><a href="https://swift/" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/</span></tt></a><tt><span style='font-size:10.0pt'>{DOMAIN_ID}_{PROJECT_ID}. </span></tt><span style='font-family:"Arial","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. </span><br><br><span style='font-family:"Arial","sans-serif"'>Best Regards,</span> <br><span style='font-family:"Arial","sans-serif"'>Alex. </span><br><br><br><br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>From: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Chuck Thier <<a href="mailto:cthier@gmail.com" target="_blank">cthier@gmail.com</a>></span> <br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>To: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </span><br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>Date: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>08/01/2013 09:38 PM</span> <br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>Subject: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift</span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=3 width="100%" noshade style='color:#A0A0A0' align=center></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br><br><tt><span style='font-size:10.0pt'>Hi Henry,</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><br><tt>From a swift perspective, I think we are fine there, as we do not use</tt><br><tt>the user name or project name anywhere. At the moment, I'm thinking</tt><br><tt>that we can do auth in a similar way as we did with v2.0 api. An</tt><br><tt>"account" in swift is still tied to the project_id (which used to be</tt><br><tt>tennant_id), which is in the storage url like:</tt><br></span><a href="https://swift/AUTH_" target="_blank"><tt><span style='font-size:10.0pt'>https://SWIFT/AUTH_</span></tt></a><tt><span style='font-size:10.0pt'>{PROJECT_ID}. Keystone middleware in swift</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>validates that the given token has permission for the given Project</tt><br><tt>ID.</tt><br><br><tt>From this point of view domains are an abstract concept in keystone</tt><br><tt>only, and wouldn't mean anything directly in swift.</tt><br><br><tt>Please let me know if any of my assumptions are incorrect.</tt><br><br><tt>Thanks,</tt><br><br><tt>--</tt><br><tt>Chuck</tt><br><br><tt>On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>> wrote:</tt><br><tt>> Chuck,</tt><br><tt>></tt><br><tt>> 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: </tt></span><a href="https://review.openstack.org/#/c/18805/" target="_blank"><tt><span style='font-size:10.0pt'>https://review.openstack.org/#/c/18805/</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>></tt><br><tt>> 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.</tt><br><tt>></tt><br><tt>> Henry</tt><br><tt>> On 8 Jan 2013, at 19:05, Chuck Thier wrote:</tt><br><tt>></tt><br><tt>>> Yeah, I was hoping for more clarity, as it would help to figure out</tt><br><tt>>> how to best map the concepts in swift. A couple of quick questions</tt><br><tt>>> come to mind. When a request is validated, is the domain required, or</tt><br><tt>>> is a user_id and project_id sufficient? Is the concept of a domain</tt><br><tt>>> useful in the context of swift?</tt><br><tt>>></tt><br><tt>>> --</tt><br><tt>>> Chuck</tt><br><tt>>></tt><br><tt>>> On Tue, Jan 8, 2013 at 11:37 AM, heckj <<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>> wrote:</tt><br><tt>>>> The best is probably </tt></span><a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md" target="_blank"><tt><span style='font-size:10.0pt'>https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md</span></tt></a><tt><span style='font-size:10.0pt'>, but it's a bit light on use-cases around the concepts I'm afraid.</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>></tt><br><tt>>>> -joe</tt><br><tt>>>></tt><br><tt>>>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <<a href="mailto:cthier@gmail.com" target="_blank">cthier@gmail.com</a>> wrote:</tt><br><tt>>>>> Is there documentation anywhere that defines all of these, and the use</tt><br><tt>>>>> cases? That would help us figure out how to map these concepts to</tt><br><tt>>>>> swift.</tt><br><tt>>>>></tt><br><tt>>>>> --</tt><br><tt>>>>> Chuck</tt><br><tt>>>>></tt><br><tt>>>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>> wrote:</tt><br><tt>>>>>> I think it would be practical to expose the authenticated user's DOMAIN_ID</tt><br><tt>>>>>> and DOMAIN_NAME into the request environment for the underlying service /</tt><br><tt>>>>>> middleware to consume, as we do today with TENANT_ID / TENANT_NAME (soon to</tt><br><tt>>>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).</tt><br><tt>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>> -Dolph</tt><br><tt>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg</tt><br><tt>>>>>> <<a href="mailto:SHULMANA@il.ibm.com" target="_blank">SHULMANA@il.ibm.com</a>> wrote:</tt><br><tt>>>>>>></tt><br><tt>>>>>>> Hi,</tt><br><tt>>>>>>></tt><br><tt>>>>>>> As most of you know, Keystone v3 API will introduce the notions of</tt><br><tt>>>>>>> "domains" and "projects" which will replace the existing notion of tenants.</tt><br><tt>>>>>>> It is important to allow using the same concepts in Swift. Since different</tt><br><tt>>>>>>> domains may represent different companies, it is important to allow</tt><br><tt>>>>>>> reflecting the Keystone "domain name" in the Swift "account name", providing</tt><br><tt>>>>>>> an option to isolate the requests of different domains. Are there existing</tt><br><tt>>>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would like to start</tt><br><tt>>>>>>> discussing the potential solutions.</tt><br><tt>>>>>>></tt><br><tt>>>>>>> Thank you all,</tt><br><tt>>>>>>> Alex.</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> ----------------------------------------------------------</tt><br><tt>>>>>>> Alexandra Shulman-Peleg, PhD</tt><br><tt>>>>>>> Storage Research, Cloud Platforms Dept.</tt><br><tt>>>>>>> IBM Haifa Research Lab</tt><br><tt>>>>>>> Tel: <a href="tel:%2B972-3-7689530" target="_blank">+972-3-7689530</a> | Fax: <a href="tel:%2B972-3-7689545" target="_blank">+972-3-7689545</a></tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> _______________________________________________</tt><br><tt>>>>>>> OpenStack-dev mailing list</tt><br><tt>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>> _______________________________________________</tt><br><tt>>>>>> OpenStack-dev mailing list</tt><br><tt>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>>></tt><br><tt>>>>></tt><br><tt>>>>> _______________________________________________</tt><br><tt>>>>> OpenStack-dev mailing list</tt><br><tt>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>></tt><br><tt>>>></tt><br><tt>>>> _______________________________________________</tt><br><tt>>>> OpenStack-dev mailing list</tt><br><tt>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>></tt><br><tt>>> _______________________________________________</tt><br><tt>>> OpenStack-dev mailing list</tt><br><tt>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>></tt><br><tt>></tt><br><tt>></tt><br><tt>> _______________________________________________</tt><br><tt>> OpenStack-dev mailing list</tt><br><tt>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><br><tt>_______________________________________________</tt><br><tt>OpenStack-dev mailing list</tt><br><tt><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><br></span><o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></body></html>