On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews <dolph.math...@gmail.com> wrote:
> 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: > > > https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523 > > 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. > > But we do **not** have a use case to add groups to *all* Fernet payloads: > only to token creation & validation responses. > 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. [0] https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/common.py#L413 [1] https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/identity/core.py#L977 > > On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg <morgan.fainb...@gmail.com > > wrote: > >> 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* >>> <dolph.math...@gmail.com>> wrote: >>> >>> >>> On Wed, Jun 3, 2015 at 5:58 PM, John Wood <*john.w...@rackspace.com* >>> <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* >>> <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* >>> <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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* >>> <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* >>> <openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* >>> <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 > >
__________________________________________________________________________ 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