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.
--Morgan Sent via mobile > On Jun 3, 2015, at 21:51, Lance Bragstad <lbrags...@gmail.com> wrote: > > 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. > > 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. > > > 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. > > > [0] > https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z > >> On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli <steve...@ca.ibm.com> >> wrote: >> Dozens to hundreds of roles or endpoints could cause an issue now :) >> >> 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). >> >> Thanks, >> >> Steve Martinelli >> OpenStack Keystone Core >> >> >> >> From: "Fox, Kevin M" <kevin....@pnnl.gov> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: 06/03/2015 11:14 PM >> Subject: Re: [openstack-dev] [keystone][barbican] Regarding >> exposing X-Group-xxxx in token validation >> >> >> >> Will dozens to a hundred groups or so on one user cause issues? :) >> >> Thanks, >> Kevin >> >> From: Morgan Fainberg >> Sent: Wednesday, June 03, 2015 7:23:22 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing >> X-Group-xxxx in token validation >> >> 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. >> >> --Morgan >> >> Sent via mobile >> >> On Jun 3, 2015, at 18:44, Dolph Mathews <dolph.math...@gmail.com> wrote: >> >> >> On Wed, Jun 3, 2015 at 5:58 PM, John Wood <john.w...@rackspace.com> wrote: >> Hello folks, >> >> 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. >> >> 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). >> >> 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. >> >> 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): >> >> >> https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token >> >> >> This would allow us to address bugs such as: >> >> https://bugs.launchpad.net/keystone/+bug/1268751 >> >> 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? >> >> >> Would the community consider this a useful feature? Would the community >> consider adding this support to Liberty? >> >> Thank you, >> John >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
