Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150605/f6e489f0/attachment.html>