settingsLogin | Registersettings

[openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

0 votes

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).

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 3, 2015 in openstack-dev by John_Wood (2,140 points)   1 3

21 Responses

0 votes

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@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@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@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.mathews@gmail.com wrote:

On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.nash@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@gmail.com To: "OpenStack
Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>, Henry Nash <
henryn@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.wood@rackspace.com
john.wood@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: *, Kevin M <Kevin.Fox@pnnl.gov* Kevin.Fox@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 groupid 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@gmail.com
dolph.mathews@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%2Cdomainid%3D456%2Cname%3Dabc,id%3D789%2Cdomainid%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@gmail.com
dolph.mathews@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@gmail.com morgan.fainberg@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@gmail.com
lbragstad@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@ca.ibm.com
stevemar@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@pnnl.gov Kevin.Fox@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.mathews@gmail.com
dolph.mathews@gmail.com> wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood <john.wood@rackspace.com
john.wood@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@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@lists.openstack.org
OpenStack-dev-request@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@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@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@lists.openstack.org
OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe

*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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 12, 2015 by Dolph_Mathews (9,560 points)   1 2 3
...