<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">In Juno I tried adding a user in Domain A to group in Domain B. That currently is not supported. Would be very handy though.<br>
<br>
We're getting a ways from the original part of the thread, so I may have lost some context, but I think the original question was, if barbarian can add group names to their resource acls.<br>
<br>
Since two administrative domains can issue the same group name, its not safe I believe.<br>
<br>
Simply ensuring the group name is associated with a user and the domain for the user matches the domain for the group wouldn't work because someone with control of their own domain can just make a
<br>
user and give them the group with the name they want and come take your credentials.<br>
<br>
What may be safe is for the barbican ACL to contain the group_id if they are uniqueue across all domains, or take a domain_id & group_name pair for the acl.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF593513"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Dolph Mathews [dolph.mathews@gmail.com]<br>
<b>Sent:</b> Thursday, June 04, 2015 1:41 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Problem! In writing a spec for this ( <a href="https://review.openstack.org/#/c/188564/" target="_blank">
https://review.openstack.org/#/c/188564/</a> ), I remembered that groups are domain-specific entities, which complicates the problem of providing X-Group-Names via middleware.
<div>
<div><br>
</div>
<div>The problem is that we can't simply expose X-Group-Names to underlying services without either A) making a well-documented assumption about the ONE owning domain scope of ALL included groups, B) passing significantly more data to underlying services than
 just a list of names (a domain scope for every group), C) passing only globally-unique group IDs (services would then have to retrieve additional details about each from from keystone if they so cared).</div>
<div><br>
</div>
<div>Option A) More specifically, keystone could opt to enumerate the groups that belong to the same domain as the user. In this case, it'd probably make more sense from an API perspective if the "groups" enumeration were part of the "user" resources in the
 token response body (the "user" object already has a containing domain ID. That means that IF a user were to be assigned a group membership in another domain (assuming we didn't move to disallowing that behavior at some point), then it would have to be excluded
 from this list. If that were true, then I'd also follow that X-Group-Names become X-User-Group-Names, so that it might be more clear that they belong to the X-User-Domain-*.</div>
<div><br>
</div>
<div>Option B) This is probably the most complex solution, but also the most explicit. I have no idea how this interface would look in terms of headers using current conventions. If we're going to break conventions, then I'd want to pass a id+domain_id+name
 for each group reference. So, rather than including a list of names AND a list of IDs, we'd have some terribly encoded list of group objects (I'm not sure what the HTTP convention is on this sort of use case, and hoping someone can illustrate a better solution
 given the representation below):</div>
<div><br>
</div>
<div>  X-Groups: id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef</div>
<div><br>
</div>
<div>Option C) Federated tokens would actually require solution (C) today because they only include group IDs, not names. But the group enumeration in federated tokens was also only intended to be consumed by keystone, so that's not really an issue for that
 one use case. But option (C) would mean there are no X-Group-Names passed to services, just X-Group-Ids. I'm guessing this won't provide the user experience that Barbican is looking for?</div>
<div><br>
</div>
<div><br>
</div>
<div>I'm leaning towards solution (A), but curious if that'll work for Barbican and/or if anyone has an idea that I'm overlooking.</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews <span dir="ltr">
<<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr">To clarify: we already have to include the groups produced as a result of federation mapping **in the payload** of Fernet tokens so that scoped tokens can be created later:
<div><br>
</div>
<div>  <a href="https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523" target="_blank">https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523</a></div>
<div><br>
</div>
<div>These are OpenStack group IDs, so it's up to the deployer to keep those under control to keep Fernet token sizes down. It's the only place in the current Fernet implementation that's (somewhat alarmingly) unbounded in the real world.</div>
<div><br>
</div>
<div>But we do **not** have a use case to add groups to *all* Fernet payloads: only to token creation & validation responses.
<div>
<div class="h5"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg <span dir="ltr">
<<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-color:rgb(204,204,204); border-left-style:solid; padding-left:1ex">
<div dir="auto">
<div>For Fernet, the groups would only be populated on validate as Dolph outlined. They would not be added to the core payload. We do not want to expand the payload in this manner. </div>
<div><br>
</div>
<div>--Morgan<br>
<br>
Sent via mobile</div>
<div>
<div>
<div><br>
On Jun 3, 2015, at 21:51, Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">I feel if we allowed group ids to be an attribute of the Fernet's core payload, we continue to open up the possibility for tokens to be greater than the initial "acceptable" size limit for a Fernet token (which I believe was 255 bytes?). With
 this, I think we need to provide guidance on the number of group ids allowed within the token before that size limit is compromised.
<div><br>
</div>
<div>We've landed patches recently that allow for id strings to be included in the Fernet payload [0], regardless of being uuid format (which can be converted to bytes before packing to save space, this is harder for us to do with non-uuid format id strings).
 This can also cause the Fernet token size to grow. If we plan to include more information in the Fernet token payload I think we should determine if the original acceptable size limit still applies and regardless of what that size limit is provide some sort
 of "best practices" for helping deployments keep their token size as small as possible.</div>
<div><br>
</div>
<div><br>
</div>
<div>Keeping the tokens user (and developer) friendly was a big plus in the design of Fernet, and providing resource for deployments to maintain that would be helpful.</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a href="https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z" target="_blank">https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z</a></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli <span dir="ltr">
<<a href="mailto:stevemar@ca.ibm.com" target="_blank">stevemar@ca.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-color:rgb(204,204,204); border-left-style:solid; padding-left:1ex">
<font face="sans-serif" size="2">Dozens to hundreds of roles or endpoints could cause an issue now :)</font>
<br>
<br>
<font face="sans-serif" size="2">But yeah, groups are much more likely to number in the dozens than roles or endpoints. But I think the Fernet token size is so small that it could probably handle this (since it does so now for the federated workflow).</font>
<br>
<font face="sans-serif" size="2"><br>
Thanks,<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Core</font> <br>
<br>
<br>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">From:        </font><font face="sans-serif" size="1">"Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></font>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">To:        </font><font face="sans-serif" size="1">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font>
<br>
<font face="sans-serif" size="1" color="#5f5f5f">Date:        </font><font face="sans-serif" size="1">06/03/2015 11:14 PM</font>
<br>
<span><font face="sans-serif" size="1" color="#5f5f5f">Subject:        </font><font face="sans-serif" size="1">Re: [openstack-dev] [keystone][barbican] Regarding        exposing        X-Group-xxxx in token validation</font>
<br>
</span>
<hr noshade="">
<div>
<div><br>
<br>
<br>
<font size="3">Will dozens to a hundred groups or so on one user cause issues? :)<br>
<br>
Thanks,<br>
Kevin </font><br>
<font face="Tahoma" size="2"><b> </b></font> <br>
<hr>
<font face="Tahoma" size="2"><b>From:</b> Morgan Fainberg<b><br>
Sent:</b> Wednesday, June 03, 2015 7:23:22 PM<b><br>
To:</b> OpenStack Development Mailing List (not for usage questions)<b><br>
Subject:</b> Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation</font><font size="3"><br>
</font><br>
<font size="3">In general I am of the opinion with the move to Fernet there is no good reason we should avoid adding the group information into the token.
</font><br>
<br>
<font size="3">--Morgan<br>
<br>
Sent via mobile</font> <br>
<font size="3"><br>
On Jun 3, 2015, at 18:44, Dolph Mathews <</font><a href="mailto:dolph.mathews@gmail.com" target="_blank"><font size="3" color="blue"><u>dolph.mathews@gmail.com</u></font></a><font size="3">> wrote:<br>
</font><br>
<br>
<font size="3">On Wed, Jun 3, 2015 at 5:58 PM, John Wood <</font><a href="mailto:john.wood@rackspace.com" target="_blank"><font size="3" color="blue"><u>john.wood@rackspace.com</u></font></a><font size="3">> wrote:</font>
<br>
<font face="Calibri" size="1" color="blue">Hello folks,</font> <br>
<br>
<font face="Calibri" size="1" color="blue">There has been discussion about adding user group support to the per-secret access control list (ACL) feature in Barbican. Hence secrets could be marked as accessible by a group on the ACL rather than an individual
 user as implemented now.</font> <br>
<br>
<font face="Calibri" size="1" color="blue">Our understanding is that Keystone does not pass along a user’s group information during token validation however (such as in the form of X-Group-Ids/X-Group-Names headers passed along via Keystone middleware).</font>
<br>
<br>
<font size="3">The pre-requisite for including that information in the form of headers would be adding group information to the token validation response. In the case of UUID, it would be pre-computed and stored in the DB at token creation time. In the case
 of PKI, it would be encoded into the PKI token and further bloat PKI tokens. And in the case of Fernet, it would be included at token validation time.</font>
<br>
<br>
<font size="3">Including group information, however, would also let us efficient revoke tokens using token revocation events when group membership is affected in any way (user being removed from a group, a group being deleted, or a group-based role assignment
 being revoked). The OS-FEDERATION extension is actually already including groups in tokens today, as a required part of the federated workflow. We'd effectively be introducing that same behavior into the core Identity API (see the federated token example):</font>
<br>
<br>
<font size="3">  </font><a href="https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token" target="_blank"><font size="3" color="blue"><u>https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token</u></font></a>
<br>
<br>
<font size="3">This would allow us to address bugs such as:</font> <br>
<br>
<font size="3">  </font><a href="https://bugs.launchpad.net/keystone/+bug/1268751" target="_blank"><font size="3" color="blue"><u>https://bugs.launchpad.net/keystone/+bug/1268751</u></font></a>
<br>
<br>
<font size="3">In the past, we shied away from including groups if only to avoid bloating the size of PKI tokens any further (but now we have Fernet tokens providing a viable alternative). Are there any other reasons not to add group information to the token
 validation response?</font> <br>
<font size="3"> </font> <br>
<br>
<font face="Calibri" size="1" color="blue">Would the community consider this a useful feature? Would the community consider adding this support to Liberty?</font>
<br>
<br>
<font face="Calibri" size="1" color="blue">Thank you,</font> <br>
<font face="Calibri" size="1" color="blue">John</font> <br>
<br>
<font size="3"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3"><br>
</font><br>
<br>
<font size="3">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><font size="3" color="blue"><u>OpenStack-dev-request@lists.openstack.org</u></font></a><font size="3">?subject:unsubscribe</font><font size="3" color="blue"><u><br>
</u></font></div>
</div>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><tt><font size="2">__________________________________________________________________________<span><br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</span></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size="2"><br>
</font></tt><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>__________________________________________________________________________</span><br>
<span>OpenStack Development Mailing List (not for usage questions)</span><br>
<span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br>
<span><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></span><br>
</div>
</blockquote>
</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" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>