Open Stack

On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews <dolph.mathews at 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.fainberg at 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 <lbragstad at 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 <stevemar at 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.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*
>>> <dolph.mathews at gmail.com>> wrote:
>>>
>>>
>>> On Wed, Jun 3, 2015 at 5:58 PM, John Wood <*john.wood at rackspace.com*
>>> <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*
>>> <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-request at lists.openstack.org?subject:unsubscribe*
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org*
>>> <OpenStack-dev-request at 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-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
>>
>>
>> __________________________________________________________________________
>> 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/20150604/26e1925b/attachment.html>