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

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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

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 wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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?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 4, 2015 by Morgan_Fainberg (17,320 points)   2 6 9
0 votes

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 wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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?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 4, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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
To: "OpenStack Development Mailing List (not for usage questions)"

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 wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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?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 4, 2015 by Steve_Martinelli (6,500 points)   1 3 6
0 votes

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

On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli 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
To: "OpenStack Development Mailing List (not for usage questions)"
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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 4, 2015 by Lance_Bragstad (11,080 points)   2 3 6
0 votes

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

On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli 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
To: "OpenStack Development Mailing List (not for usage questions)" 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 wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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?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?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 4, 2015 by Morgan_Fainberg (17,320 points)   2 6 9
0 votes

Some kind of intermediate mapping might be better. With ldap, I dont have control over the groups users are assigned since thats an enterprise/AD thing. There can be a lot of them. Groups to Role relations I guess do that mapping. Though maybe passing groups directly when domains can have different group meanings might be a big problem.

Does federation have a way to map a federated group to a local group somehow?

Thanks,
Kevin


From: Steve Martinelli
Sent: Wednesday, June 03, 2015 8:19:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

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
To: "OpenStack Development Mailing List (not for usage questions)" 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 wrote:

On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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

This would allow us to address bugs such as:

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?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 4, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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

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

On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli 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
To: "OpenStack Development Mailing List (not for usage
questions)" 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?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 4, 2015 by Dolph_Mathews (9,560 points)   1 2 3
0 votes

On 06/04/15 14:03, Fox, Kevin M wrote:
Some kind of intermediate mapping might be better. With ldap, I dont
have control over the groups users are assigned since thats an
enterprise/AD thing. There can be a lot of them. Groups to Role
relations I guess do that mapping. Though maybe passing groups directly
when domains can have different group meanings might be a big problem.

Agreed, and this has caused problems for other systems in the past.

For example the traditional AUTH_SYS as used by RPC for NFS only allowed
a user to be in 16 groups because that was all the payload could hold.
As more people moved from NIS to LDAP (and for some even when in NIS or
NIS+) 16 groups was a big issue.

Now modern Linux and Solaris kernels support a user being in 1024 groups
by having the consumer (the NFS server usually) check with the directory
server (usually LDAP) when the list is exactly 16 groups.

So we know it is already common for LDAP directories to have users in a
significant number of groups.

--
Darren J Moffat


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 4, 2015 by Darren_J_Moffat (340 points)   1
0 votes

On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews 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

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.

Ah, that makes sense. So we would be adding logic to gettokendata() [0]
that would allow for groups to be populated in the response based on the
user id? For that we shouldn't need anything in the token outside of the
userid, right? We would just need gettokendata to call the identityapi
for the groups a user belongs to [1]. This makes sense, I was thinking we
were going to pull all groups inside the Fernet payload.

[0]
https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/common.py#L413
[1]
https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/identity/core.py#L977

On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg <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 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

On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli 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
To: "OpenStack Development Mailing List (not for usage
questions)" 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
?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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 4, 2015 by Lance_Bragstad (11,080 points)   2 3 6
...