<div dir="ltr"><br><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: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="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></blockquote><div><br></div><div>Ah, that makes sense. So we would be adding logic to get_token_data() [0] that would allow for groups to be populated in the response based on the user id? For that we shouldn't need anything in the token outside of the user_id, right? We would just need get_token_data to call the identity_api for the groups a user belongs to [1]. This makes sense, I was thinking we were going to pull all groups *inside* the Fernet payload.</div><div><br></div><div>[0] <a href="https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/common.py#L413">https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/common.py#L413</a></div><div>[1] <a href="https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/identity/core.py#L977">https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/identity/core.py#L977</a></div><div><br></div><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="ltr"><div><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 size="2" face="sans-serif">Dozens to hundreds of roles or endpoints
could cause an issue now :)</font>
<br>
<br><font size="2" face="sans-serif">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 size="2" face="sans-serif"><br>
Thanks,<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Core</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">"Fox, Kevin M"
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">"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 size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">06/03/2015 11:14 PM</font>
<br><span><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">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 size="2" face="Tahoma"><b> </b></font>
<br>
<hr><font size="2" face="Tahoma"><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 size="1" color="blue" face="Calibri">Hello folks,</font>
<br>
<br><font size="1" color="blue" face="Calibri">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 size="1" color="blue" face="Calibri">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 size="1" color="blue" face="Calibri">Would the community consider
this a useful feature? Would the community consider adding this support
to Liberty?</font>
<br>
<br><font size="1" color="blue" face="Calibri">Thank you,</font>
<br><font size="1" color="blue" face="Calibri">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>
<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>