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<mailto:dolph.math...@gmail.com>> wrote:


On Wed, Jun 3, 2015 at 5:58 PM, John Wood 
<john.w...@rackspace.com<mailto: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://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<mailto: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

Reply via email to