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.math...@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.w...@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 <henryna...@mac.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Friday, June 5, 2015 at 12:49 PM >> >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@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.math...@gmail.com> wrote: >> >> >> On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash <henry.n...@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.math...@gmail.com> To: "OpenStack >>> Development Mailing List (not for usage questions)" < >>> openstack-dev@lists.openstack.org>, Henry Nash < >>> hen...@linux.vnet.ibm.com>, Henry Nash/UK/IBM@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.w...@rackspace.com* >>> <john.w...@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....@pnnl.gov* <kevin....@pnnl.gov>> >>> * Reply-To: *"OpenStack Development Mailing List (not for usage >>> questions)" <*openstack-dev@lists.openstack.org* >>> <openstack-dev@lists.openstack.org>> >>> * Date: *Thursday, June 4, 2015 at 6:01 PM >>> * To: *"OpenStack Development Mailing List (not for usage questions)" < >>> *openstack-dev@lists.openstack.org* <openstack-dev@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.math...@gmail.com* >>> <dolph.math...@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.math...@gmail.com* >>> <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* >>> <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.fainb...@gmail.com* <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* >>> <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* >>> <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* >>> <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* <kevin....@pnnl.gov>> >>> To: "OpenStack Development Mailing List (not for usage >>> questions)" <*openstack-dev@lists.openstack.org* >>> <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://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://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://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://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> >>> >>> >>> >>> >>> 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-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