Open Stack

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.Fox at pnnl.gov>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at 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.mathews at gmail.com> wrote:


On Wed, Jun 3, 2015 at 5:58 PM, John Wood <john.wood at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/a4fab4e6/attachment.html>