Open Stack

Just to follow up, I've posted a revised specification which only include
group *IDs* in tokens (so, effectively promoting OS-FEDERATION's behavior
to core without modification) and mention of an X-Group-Ids header in
keystonemiddleware.auth_token:

  https://review.openstack.org/#/c/188564/

On Wed, Jun 10, 2015 at 10:47 AM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

> We're aiming for a Spec "Proposal" Freeze deadline for Liberty of June
> 23rd, but are requiring that specs are approved by our spec reviewers by
> that date. The spec [1] is currently pretty straightforward and provides us
> several benefits, so I don't expect it to be a complicated process, but is
> currently pending a revision from myself. I'm confident in Liberty at this
> point.
>
> [1] https://review.openstack.org/#/c/188564/
>
> On Wed, Jun 10, 2015 at 10:35 AM, John Wood <john.wood at rackspace.com>
> wrote:
>
>>  Hello folks,
>>
>>  Thanks for the consideration of this feature. Does it seem realistic
>> for a Liberty release of Keystone middleware to expose X-Group-Ids, or
>> would this be an M and beyond sort of thing?
>>
>>  Thanks,
>> John
>>
>>
>>   From: Henry Nash <henrynash9 at mac.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Friday, June 5, 2015 at 12:49 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing
>> X-Group-xxxx in token validation
>>
>>   The one proviso is that in single LDAP situations, the cloud provider
>> can chose (for backward compatibility reasons) to allow the underlying LDAP
>> user/group ID….so we might want to advise this to be disabled (there’s a
>> config switch to use the Public ID mapping for even this case).
>>
>>  Henry
>>
>> On 5 Jun 2015, at 18:19, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>>
>>
>> On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash <henry.nash at uk.ibm.com>
>> wrote:
>>
>>> So I think that GroupID's are actually unique and safe....since in the
>>> multi LDAP case we provide an indirection already in Keystone and issue a
>>> "Public ID" (this is true for bother users and groups), that we map to the
>>> underlying local ID in the particular LDAP backend.
>>
>>
>>  Oh, awesome! I didn't realize we did that for groups as well. So then,
>> we're safe exposing X-Group-Ids to services via
>> keystonemiddleware.auth_token but still not X-Group-Names (in any trivial
>> form).
>>
>>
>>>
>>>
>>> Henry
>>>
>>>
>>>   From:  Dolph Mathews <dolph.mathews at gmail.com>  To:  "OpenStack
>>> Development Mailing List (not for usage questions)" <
>>> openstack-dev at lists.openstack.org>, Henry Nash <
>>> henryn at linux.vnet.ibm.com>, Henry Nash/UK/IBM at IBMGB   Date:  05/06/2015
>>> 15:38   Subject:  Re: [openstack-dev] [keystone][barbican] Regarding
>>> exposing X-Group-xxxx in token validation
>>>
>>> ------------------------------
>>>
>>>
>>>
>>>
>>> On Thu, Jun 4, 2015 at 10:17 PM, John Wood <*john.wood at rackspace.com*
>>> <john.wood at rackspace.com>> wrote:
>>> Hello folks,
>>>
>>> Regarding option C, if group IDs are unique within a given
>>> cloud/context, and these are discoverable by clients that can then set the
>>> ACL on a secret in Barbican, then that seems like a viable option to me. As
>>> it is now, the user information provided to the ACL is the user ID
>>> information as found in X-User-Ids now, not user names.
>>>
>>> To Kevin’s point though, are these group IDs unique across domains now,
>>> or in the future? If not the more complex tuples suggested could be used,
>>> but seem more error prone to configure on an ACL.
>>>
>>> Well, that's a good question, because that depends on the backend, and
>>> our backend architecture has recently gotten very complicated in this area.
>>>
>>> If groups are backed by SQL, then they're going to be globally unique
>>> UUIDs, so the answer is always yes.
>>>
>>> If they're backed by LDAP, then actually it depends on LDAP, but the
>>> answer should be yes.
>>>
>>> But the nightmare scenario we now support is domain-specific identity
>>> drivers, where each domain can actually be configured to talk to a
>>> different LDAP server. In that case, I don't think you can make any
>>> guarantees about group ID uniqueness :( Instead, each domain could provide
>>> whatever IDs it wants, and those might conflict with those of other
>>> domains. We have a workaround for a similar issue with user IDs, but it
>>> hasn't been applied to groups, leaving them quite broken in this scenario.
>>> I'd consider this to be an issue we need to solve in Keystone, though, not
>>> something other projects need to worry about. I'm hoping Henry Nash can
>>> chime in and correct me!
>>>
>>>
>>> Thanks,
>>> John
>>>
>>> *From: *<Fox>, Kevin M <*Kevin.Fox at pnnl.gov* <Kevin.Fox at pnnl.gov>>
>>> * Reply-To: *"OpenStack Development Mailing List (not for usage
>>> questions)" <*openstack-dev at lists.openstack.org*
>>> <openstack-dev at lists.openstack.org>>
>>> * Date: *Thursday, June 4, 2015 at 6:01 PM
>>> * To: *"OpenStack Development Mailing List (not for usage questions)" <
>>> *openstack-dev at lists.openstack.org* <openstack-dev at lists.openstack.org>>
>>>
>>> * Subject: *Re: [openstack-dev] [keystone][barbican] Regarding exposing
>>> X-Group-xxxx in token validation
>>>
>>> In Juno I tried adding a user in Domain A to group in Domain B. That
>>> currently is not supported. Would be very handy though.
>>>
>>> We're getting a ways from the original part of the thread, so I may have
>>> lost some context, but I think the original question was, if barbarian can
>>> add group names to their resource acls.
>>>
>>> Since two administrative domains can issue the same group name, its not
>>> safe I believe.
>>>
>>> Simply ensuring the group name is associated with a user and the domain
>>> for the user matches the domain for the group wouldn't work because someone
>>> with control of their own domain can just make a
>>> user and give them the group with the name they want and come take your
>>> credentials.
>>>
>>> What may be safe is for the barbican ACL to contain the group_id if they
>>> are uniqueue across all domains, or take a domain_id & group_name pair for
>>> the acl.
>>>
>>> Thanks,
>>> Kevin
>>>
>>> ------------------------------
>>>
>>> *From:* Dolph Mathews [*dolph.mathews at gmail.com*
>>> <dolph.mathews at gmail.com>]
>>> * Sent:* Thursday, June 04, 2015 1:41 PM
>>> * To:* OpenStack Development Mailing List (not for usage questions)
>>> * Subject:* Re: [openstack-dev] [keystone][barbican] Regarding exposing
>>> X-Group-xxxx in token validation
>>>
>>> Problem! In writing a spec for this (
>>> *https://review.openstack.org/#/c/188564/*
>>> <https://review.openstack.org/#/c/188564/> ), I remembered that groups
>>> are domain-specific entities, which complicates the problem of providing
>>> X-Group-Names via middleware.
>>>
>>> The problem is that we can't simply expose X-Group-Names to underlying
>>> services without either A) making a well-documented assumption about the
>>> ONE owning domain scope of ALL included groups, B) passing significantly
>>> more data to underlying services than just a list of names (a domain scope
>>> for every group), C) passing only globally-unique group IDs (services would
>>> then have to retrieve additional details about each from from keystone if
>>> they so cared).
>>>
>>> Option A) More specifically, keystone could opt to enumerate the groups
>>> that belong to the same domain as the user. In this case, it'd probably
>>> make more sense from an API perspective if the "groups" enumeration were
>>> part of the "user" resources in the token response body (the "user" object
>>> already has a containing domain ID. That means that IF a user were to be
>>> assigned a group membership in another domain (assuming we didn't move to
>>> disallowing that behavior at some point), then it would have to be excluded
>>> from this list. If that were true, then I'd also follow that X-Group-Names
>>> become X-User-Group-Names, so that it might be more clear that they belong
>>> to the X-User-Domain-*.
>>>
>>> Option B) This is probably the most complex solution, but also the most
>>> explicit. I have no idea how this interface would look in terms of headers
>>> using current conventions. If we're going to break conventions, then I'd
>>> want to pass a id+domain_id+name for each group reference. So, rather than
>>> including a list of names AND a list of IDs, we'd have some terribly
>>> encoded list of group objects (I'm not sure what the HTTP convention is on
>>> this sort of use case, and hoping someone can illustrate a better solution
>>> given the representation below):
>>>
>>>   X-Groups:
>>> id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef
>>>
>>> Option C) Federated tokens would actually require solution (C) today
>>> because they only include group IDs, not names. But the group enumeration
>>> in federated tokens was also only intended to be consumed by keystone, so
>>> that's not really an issue for that one use case. But option (C) would mean
>>> there are no X-Group-Names passed to services, just X-Group-Ids. I'm
>>> guessing this won't provide the user experience that Barbican is looking
>>> for?
>>>
>>>
>>> I'm leaning towards solution (A), but curious if that'll work for
>>> Barbican and/or if anyone has an idea that I'm overlooking.
>>>
>>>
>>> On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews <*dolph.mathews at gmail.com*
>>> <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*
>>> <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.
>>>
>>>
>>> On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg <
>>> *morgan.fainberg at gmail.com* <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*
>>> <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*
>>> <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*
>>> <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* <Kevin.Fox at pnnl.gov>>
>>> To:        "OpenStack Development Mailing List (not for usage
>>> questions)" <*openstack-dev at lists.openstack.org*
>>> <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://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?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://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?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>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>>> 3AU
>>>
>>
>>
>> __________________________________________________________________________
>> 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/20150612/f15e0354/attachment-0001.html>