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 > <mailto: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 <mailto:dolph.math...@gmail.com>> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>>, Henry Nash > <hen...@linux.vnet.ibm.com <mailto: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 > <mailto: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 <mailto:kevin....@pnnl.gov>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto: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 > <mailto: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 <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:kevin....@pnnl.gov>> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto: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 > <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 > > <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 > <mailto: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 > <mailto: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
