<div dir="ltr">I'm a bit late to the game here, and others have summed this up excellently, but i'll add my 2c. I think option 2 is the way to go, user and project IDs will absolutely work best as they are immutable.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 4:52 AM, Coles, Alistair <span dir="ltr"><<a href="mailto:alistair.coles@hpe.com" target="_blank">alistair.coles@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thai,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">(repeating some of what we have discussed in private for others’ benefit)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Swift docs state “Be sure to use Keystone UUIDs rather than names in container ACLs” [1]. The guidance is re-iterated here [2] “…names must no longer be used
 in cross-tenant ACLs…”. They then go on to explain that for backwards compatibility (i.e. to not break ACLS that have already been persisted in Swift) names in ACLs are supported in the default domain only.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The intent was not to encourage the continued use of names in the default domain (or while using keystone v2), nor to suggest that was “safe”, but to recognize
 that names had previously been used in contexts where names were unique and the ‘:’ separator was safe. In fact, Swift provides an option to disallow name matching in *<b>all</b>* contexts when no such backwards compatibility is required.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">At the time we made those changes (c. Atlanta summit) the input I had from Keystone devs was that names were not globally unique (with keystone v3), were mutable
 and should not be persisted. Hence the swift docs guidance. We actually considered preventing any new ACL being set with names, but to do so requires distinguishing a name string from a UUID string, which we didn’t find a solution for.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">So in response to your argument “If we are allowing V2 to store names [{ project, name }], I do not see why we should not allow the same for V3 [{ domain, project,
 name }]” : yes, we are allowing names in ACLs in some circumstances, but only for backwards compatibility, and we are not encouraging it. Having gone through the pain of dealing with names in existing persisted ACLs, I am reluctant to encourage their continued/renewed
 use.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Are their examples of any other projects requiring names rather than UUIDs in ACLs, or for other purposes, that we can learn from?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The idea discussed here [3] (not implemented) was that names could be supported in a JSON ACL format but should be resolved to UUIDs before persisting in Swift.
 That way a user’s name can change but since their request token is resolved to UUID then any persisted ACL would still match. As has already been mentioned in another reply on this thread, Swift has a JSON ACL format for “v1”/TempAuth account level ACLs [4]
 that could perhaps be implemented for keystoneauth and then extended to containers.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Alistair<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">[1]
<a href="http://docs.openstack.org/developer/swift/overview_auth.html#access-control-using-keystoneauth" target="_blank">
http://docs.openstack.org/developer/swift/overview_auth.html#access-control-using-keystoneauth</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">[2]
<a href="http://docs.openstack.org/developer/swift/middleware.html#keystoneauth" target="_blank">
http://docs.openstack.org/developer/swift/middleware.html#keystoneauth</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">[3]
<a href="https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3" target="_blank">https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">[4]
<a href="http://docs.openstack.org/developer/swift/overview_auth.html#tempauth" target="_blank">http://docs.openstack.org/developer/swift/overview_auth.html#tempauth</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Thai Q Tran [mailto:<a href="mailto:tqtran@us.ibm.com" target="_blank">tqtran@us.ibm.com</a>]
<br>
<b>Sent:</b> 06 June 2016 21:06<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Subject:</b> [openstack-dev] [swift][keystone] Using JSON as future ACL format<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p style="margin-bottom:12.0pt">Hello all,<br>
<br>
Hope everyone had a good weekend, and hope this email does not ruin your next.<br>
We had a small internal discussion at IBM and here are some of the findings that I will present to the wider community.<br>
<br>
1. The ":" separator that swift currently uses is not entirely safe since LDAP can be configured to allow special characters in user IDs. It essentially means no special characters are safe to use as separators. I am not sure how practical this is, but its
 something to consider.<br>
<br>
2. Since names are not guaranteed to be immutable, we should store everything via IDs. Currently, for backward compatibility reasons, Swift continues to support names for for V2. Keep in mind that V2 does not guarantee that names are immutable either. Given
 this fact and what we know from #1, we can say that names are mutable for both V2 and V3, and that any separators we use are fallible. In other words, using a separator for names or ids will not work 100% of the time.<br>
<br>
3. Keystone recently enabled URL safe naming of project and domains for their hierarchal work. As a by product of that, if the option is enabled, Swift can essentially use the reserved characters as separators. The list of reserved characters are listed below.
 The only question remaining, how does Keystone inform Swift that this option is enabled? or Swift can add an separator option that is a subset of the characters below and leave it to the deployer to configure it.<br>
<br>
<tt><span style="font-size:13.5pt">";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | ","</span></tt><br>
<br>
<a href="https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284" target="_blank">https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284</a><br>
<a href="http://www.ietf.org/rfc/rfc2396.txt" target="_blank">http://www.ietf.org/rfc/rfc2396.txt</a><br>
<br>
3. As mentioned in the KeystoneAuthACL write up in Atlanta, JSON format is one of the option going forward. The article goes on to mention that we should store only user IDs (avoiding the mutable names issue). It outlined a process and reverse-process that
 would allow names to be use but mentioned an overhead cost to Keystone. I personally think is the right approach going forward since it negate the use of a separator altogether.<br>
<br>
Whether we chose to store the user IDs or names as metadata is another issue. But on a side note, I have tested this the changing names in V2 and it has the same exact problem as V3. If we are allowing V2 to store names [{ project, name }], I do not see why
 we should not allow the same for V3 [{ domain, project, name }]. This would remove the overhead cost to Keystone. And of course, you still have the option to store things as IDs [{ domain, project, id }].<br>
<br>
<a href="https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3" target="_blank">https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3</a><br>
<br>
My intention is to spark discussion around this topic with the goal of moving the Swift community toward accepting the JSON format. Whether we store it as names or ids can be a discussion for another time. If you made it this far, thanks for reading! Your thoughts
 will be much appreciated.<br>
<br>
Thanks,<br>
Thai (tqtran)<br>
<br>
<u></u><u></u></p>
</div></div></div>
</div>
</div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>