Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
Just to follow up, I've posted a revised specification which only include group *IDs* in tokens (so, effectively promoting OS-FEDERATION's behavior to core without modification) and mention of an X-Group-Ids header in keystonemiddleware.auth_token: https://review.openstack.org/#/c/188564/ On Wed, Jun 10, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: We're aiming for a Spec Proposal Freeze deadline for Liberty of June 23rd, but are requiring that specs are approved by our spec reviewers by that date. The spec [1] is currently pretty straightforward and provides us several benefits, so I don't expect it to be a complicated process, but is currently pending a revision from myself. I'm confident in Liberty at this point. [1] https://review.openstack.org/#/c/188564/ On Wed, Jun 10, 2015 at 10:35 AM, John Wood john.w...@rackspace.com wrote: Hello folks, Thanks for the consideration of this feature. Does it seem realistic for a Liberty release of Keystone middleware to expose X-Group-Ids, or would this be an M and beyond sort of thing? Thanks, John From: Henry Nash henryna...@mac.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, June 5, 2015 at 12:49 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation The one proviso is that in single LDAP situations, the cloud provider can chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote: On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com wrote: So I think that GroupID's are actually unique and safesince in the multi LDAP case we provide an indirection already in Keystone and issue a Public ID (this is true for bother users and groups), that we map to the underlying local ID in the particular LDAP backend. Oh, awesome! I didn't realize we did that for groups as well. So then, we're safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but still not X-Group-Names (in any trivial form). Henry From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Henry Nash hen...@linux.vnet.ibm.com, Henry Nash/UK/IBM@IBMGB Date: 05/06/2015 15:38 Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation -- On Thu, Jun 4, 2015 at 10:17 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, Regarding option C, if group IDs are unique within a given cloud/context, and these are discoverable by clients that can then set the ACL on a secret in Barbican, then that seems like a viable option to me. As it is now, the user information provided to the ACL is the user ID information as found in X-User-Ids now, not user names. To Kevin’s point though, are these group IDs unique across domains now, or in the future? If not the more complex tuples suggested could be used, but seem more error prone to configure on an ACL. Well, that's a good question, because that depends on the backend, and our backend architecture has recently gotten very complicated in this area. If groups are backed by SQL, then they're going to be globally unique UUIDs, so the answer is always yes. If they're backed by LDAP, then actually it depends on LDAP, but the answer should be yes. But the nightmare scenario we now support is domain-specific identity drivers, where each domain can actually be configured to talk to a different LDAP server. In that case, I don't think you can make any guarantees about group ID uniqueness :( Instead, each domain could provide whatever IDs it wants, and those might conflict with those of other domains. We have a workaround for a similar issue with user IDs, but it hasn't been applied to groups, leaving them quite broken in this scenario. I'd consider this to be an issue we need to solve in Keystone, though, not something other projects need to worry about. I'm hoping Henry Nash can chime in and correct me! Thanks, John *From: *Fox, Kevin M *kevin@pnnl.gov* kevin@pnnl.gov * Reply-To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Date: *Thursday, June 4, 2015 at 6:01 PM * To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Subject: *Re: [openstack-dev] [keystone][barbican] Regarding
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
Hello folks, Thanks for the consideration of this feature. Does it seem realistic for a Liberty release of Keystone middleware to expose X-Group-Ids, or would this be an M and beyond sort of thing? Thanks, John From: Henry Nash henryna...@mac.commailto:henryna...@mac.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation The one proviso is that in single LDAP situations, the cloud provider can chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com wrote: On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.commailto:henry.n...@uk.ibm.com wrote: So I think that GroupID's are actually unique and safesince 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.commailto:dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, Henry Nash hen...@linux.vnet.ibm.commailto: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- in token validation On Thu, Jun 4, 2015 at 10:17 PM, John Wood john.w...@rackspace.commailto: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.govmailto:kevin@pnnl.gov Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
We're aiming for a Spec Proposal Freeze deadline for Liberty of June 23rd, but are requiring that specs are approved by our spec reviewers by that date. The spec [1] is currently pretty straightforward and provides us several benefits, so I don't expect it to be a complicated process, but is currently pending a revision from myself. I'm confident in Liberty at this point. [1] https://review.openstack.org/#/c/188564/ On Wed, Jun 10, 2015 at 10:35 AM, John Wood john.w...@rackspace.com wrote: Hello folks, Thanks for the consideration of this feature. Does it seem realistic for a Liberty release of Keystone middleware to expose X-Group-Ids, or would this be an M and beyond sort of thing? Thanks, John From: Henry Nash henryna...@mac.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, June 5, 2015 at 12:49 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation The one proviso is that in single LDAP situations, the cloud provider can chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote: On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com wrote: So I think that GroupID's are actually unique and safesince in the multi LDAP case we provide an indirection already in Keystone and issue a Public ID (this is true for bother users and groups), that we map to the underlying local ID in the particular LDAP backend. Oh, awesome! I didn't realize we did that for groups as well. So then, we're safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but still not X-Group-Names (in any trivial form). Henry From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Henry Nash hen...@linux.vnet.ibm.com, Henry Nash/UK/IBM@IBMGB Date: 05/06/2015 15:38 Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation -- On Thu, Jun 4, 2015 at 10:17 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, Regarding option C, if group IDs are unique within a given cloud/context, and these are discoverable by clients that can then set the ACL on a secret in Barbican, then that seems like a viable option to me. As it is now, the user information provided to the ACL is the user ID information as found in X-User-Ids now, not user names. To Kevin’s point though, are these group IDs unique across domains now, or in the future? If not the more complex tuples suggested could be used, but seem more error prone to configure on an ACL. Well, that's a good question, because that depends on the backend, and our backend architecture has recently gotten very complicated in this area. If groups are backed by SQL, then they're going to be globally unique UUIDs, so the answer is always yes. If they're backed by LDAP, then actually it depends on LDAP, but the answer should be yes. But the nightmare scenario we now support is domain-specific identity drivers, where each domain can actually be configured to talk to a different LDAP server. In that case, I don't think you can make any guarantees about group ID uniqueness :( Instead, each domain could provide whatever IDs it wants, and those might conflict with those of other domains. We have a workaround for a similar issue with user IDs, but it hasn't been applied to groups, leaving them quite broken in this scenario. I'd consider this to be an issue we need to solve in Keystone, though, not something other projects need to worry about. I'm hoping Henry Nash can chime in and correct me! Thanks, John *From: *Fox, Kevin M *kevin@pnnl.gov* kevin@pnnl.gov * Reply-To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Date: *Thursday, June 4, 2015 at 6:01 PM * To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Subject: *Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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
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 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 Reply-To: OpenStack Development Mailing List (not for usage questions) 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 Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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] *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- in token validation Problem! In writing a spec for this ( 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
The one proviso is that in single LDAP situations, the cloud provider can chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote: On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com mailto:henry.n...@uk.ibm.com wrote: So I think that GroupID's are actually unique and safesince 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- 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- 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- in token validation Problem! In writing a spec for this ( https://review.openstack.org/#/c/188564/ https://review.openstack.org
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com wrote: So I think that GroupID's are actually unique and safesince in the multi LDAP case we provide an indirection already in Keystone and issue a Public ID (this is true for bother users and groups), that we map to the underlying local ID in the particular LDAP backend. Oh, awesome! I didn't realize we did that for groups as well. So then, we're safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but still not X-Group-Names (in any trivial form). Henry From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Henry Nash hen...@linux.vnet.ibm.com, Henry Nash/UK/IBM@IBMGB Date: 05/06/2015 15:38 Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation -- On Thu, Jun 4, 2015 at 10:17 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, Regarding option C, if group IDs are unique within a given cloud/context, and these are discoverable by clients that can then set the ACL on a secret in Barbican, then that seems like a viable option to me. As it is now, the user information provided to the ACL is the user ID information as found in X-User-Ids now, not user names. To Kevin’s point though, are these group IDs unique across domains now, or in the future? If not the more complex tuples suggested could be used, but seem more error prone to configure on an ACL. Well, that's a good question, because that depends on the backend, and our backend architecture has recently gotten very complicated in this area. If groups are backed by SQL, then they're going to be globally unique UUIDs, so the answer is always yes. If they're backed by LDAP, then actually it depends on LDAP, but the answer should be yes. But the nightmare scenario we now support is domain-specific identity drivers, where each domain can actually be configured to talk to a different LDAP server. In that case, I don't think you can make any guarantees about group ID uniqueness :( Instead, each domain could provide whatever IDs it wants, and those might conflict with those of other domains. We have a workaround for a similar issue with user IDs, but it hasn't been applied to groups, leaving them quite broken in this scenario. I'd consider this to be an issue we need to solve in Keystone, though, not something other projects need to worry about. I'm hoping Henry Nash can chime in and correct me! Thanks, John *From: *Fox, Kevin M *kevin@pnnl.gov* kevin@pnnl.gov * Reply-To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Date: *Thursday, June 4, 2015 at 6:01 PM * To: *OpenStack Development Mailing List (not for usage questions) *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org * Subject: *Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation In Juno I tried adding a user in Domain A to group in Domain B. That currently is not supported. Would be very handy though. We're getting a ways from the original part of the thread, so I may have lost some context, but I think the original question was, if barbarian can add group names to their resource acls. Since two administrative domains can issue the same group name, its not safe I believe. Simply ensuring the group name is associated with a user and the domain for the user matches the domain for the group wouldn't work because someone with control of their own domain can just make a user and give them the group with the name they want and come take your credentials. What may be safe is for the barbican ACL to contain the group_id if they are uniqueue across all domains, or take a domain_id group_name pair for the acl. Thanks, Kevin -- *From:* Dolph Mathews [*dolph.math...@gmail.com* dolph.math...@gmail.com ] * Sent:* Thursday, June 04, 2015 1:41 PM * To:* OpenStack Development Mailing List (not for usage questions) * Subject:* Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
So I think that GroupID's are actually unique and safesince in the multi LDAP case we provide an indirection already in Keystone and issue a Public ID (this is true for BOTH users and groups), that we map to the underlying local ID in the particular LDAP backend. Henry On 5 Jun 2015, at 15:37, Dolph Mathews dolph.math...@gmail.com wrote: 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- 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- 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
I seem yo remember there being a mapping driver of some kind in juno+ that when enabled doesnt just use the ldap unique identifier raw. Its optional though. I also dont know if it doublechecks for uniqueness or just hashes. Thanks, Kevin From: Dolph Mathews Sent: Friday, June 05, 2015 7:37:54 AM To: OpenStack Development Mailing List (not for usage questions); Henry Nash; Henry Nash Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation On Thu, Jun 4, 2015 at 10:17 PM, John Wood john.w...@rackspace.commailto: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.govmailto:kevin@pnnl.gov Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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.commailto: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- in token validation Problem! In writing a spec for this ( 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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. Thanks, John From: Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- 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.commailto: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- in token validation Problem! In writing a spec for this ( 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.commailto:dolph.math...@gmail.com wrote: To clarify: we already have to include the groups
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
PM, Steve Martinelli 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 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 exposingX-Group- 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- in token validation In general I am of the opinion with the move to Fernet there is no good reason we should avoid adding the group information into the token. --Morgan Sent via mobile On Jun 3, 2015, at 18:44, Dolph Mathews *dolph.math...@gmail.com* dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, There has been discussion about adding user group support to the per-secret access control list (ACL) feature in Barbican. Hence secrets could be marked as accessible by a group on the ACL rather than an individual user as implemented now. Our understanding is that Keystone does not pass along a user’s group information during token validation however (such as in the form of X-Group-Ids/X-Group-Names headers passed along via Keystone middleware). The pre-requisite for including that information in the form of headers would be adding group information to the token validation response. In the case of UUID, it would be pre-computed and stored in the DB at token creation time. In the case of PKI, it would be encoded into the PKI token and further bloat PKI tokens. And in the case of Fernet, it would be included at token validation time. Including group information, however, would also let us efficient revoke tokens using token revocation events when group membership is affected in any way (user being removed from a group, a group being deleted, or a group-based role assignment being revoked). The OS-FEDERATION extension is actually already including groups in tokens today, as a required part of the federated workflow. We'd effectively be introducing that same behavior into the core Identity API (see the federated token example): *https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token* https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token This would allow us to address bugs such as: *https://bugs.launchpad.net/keystone/+bug/1268751* https://bugs.launchpad.net/keystone/+bug/1268751 In the past, we shied away from including groups if only to avoid bloating the size of PKI tokens any further (but now we have Fernet tokens providing a viable alternative). Are there any other reasons not to add group information to the token validation response? Would the community consider this a useful feature? Would the community consider adding this support to Liberty? Thank you, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe* http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: *openstack-dev-requ...@lists.openstack.org* openstack-dev-requ...@lists.openstack.org?subject:unsubscribe *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ
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] 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- in token validation Problem! In writing a spec for this ( 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.commailto: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 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.commailto: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.commailto:lbrags...@gmail.com wrote: I feel if we allowed group ids
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews 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 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 get_token_data() [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 user_id, right? We would just need get_token_data to call the identity_api 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.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 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 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 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 exposingX-Group- 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- in token validation In general I am of the opinion with the move to Fernet there is no good reason we should avoid adding the group information into the token. --Morgan Sent via mobile On Jun 3, 2015, at 18:44, Dolph Mathews *dolph.math...@gmail.com* dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, There has been discussion about adding user group support to the per-secret access control list (ACL) feature in Barbican. Hence secrets could be marked as accessible by a group on the ACL rather than an individual user as implemented now. Our understanding is that Keystone does not pass along a user’s group information during token validation however (such as in the form of X
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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 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 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 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 exposingX-Group- 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- 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 wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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 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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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- 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@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 exposingX-Group- 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- 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.commailto:dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood john.w...@rackspace.commailto: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 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-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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.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 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 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 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 exposingX-Group- 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- in token validation In general I am of the opinion with the move to Fernet there is no good reason we should avoid adding the group information into the token. --Morgan Sent via mobile On Jun 3, 2015, at 18:44, Dolph Mathews *dolph.math...@gmail.com* dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, There has been discussion about adding user group support to the per-secret access control list (ACL) feature in Barbican. Hence secrets could be marked as accessible by a group on the ACL rather than an individual user as implemented now. Our understanding is that Keystone does not pass along a user’s group information during token validation however (such as in the form of X-Group-Ids/X-Group-Names headers passed along via Keystone middleware). The pre-requisite for including that information in the form of headers would be adding group information to the token validation response. In the case of UUID, it would be pre-computed and stored in the DB at token creation time. In the case of PKI, it would be encoded into the PKI token and further bloat PKI tokens. And in the case of Fernet, it would be included at token validation time. Including group information, however, would also let us efficient revoke tokens using token revocation events when group membership is affected in any way (user being removed from a group, a group being deleted, or a group-based role assignment being revoked). The OS-FEDERATION extension
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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- 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.commailto:dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood john.w...@rackspace.commailto: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 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-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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 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-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
Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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 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 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 exposingX-Group- 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- in token validation In general I am of the opinion with the move to Fernet there is no good reason we should avoid adding the group information into the token. --Morgan Sent via mobile On Jun 3, 2015, at 18:44, Dolph Mathews *dolph.math...@gmail.com* dolph.math...@gmail.com wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood *john.w...@rackspace.com* john.w...@rackspace.com wrote: Hello folks, There has been discussion about adding user group support to the per-secret access control list (ACL) feature in Barbican. Hence secrets could be marked as accessible by a group on the ACL rather than an individual user as implemented now. Our understanding is that Keystone does not pass along a user’s group information during token validation however (such as in the form of X-Group-Ids/X-Group-Names headers passed along via Keystone middleware). The pre-requisite for including that information in the form of headers would be adding group information to the token validation response. In the case of UUID, it would be pre-computed and stored in the DB at token creation time. In the case of PKI, it would be encoded into the PKI token and further bloat PKI tokens. And in the case of Fernet, it would be included at token validation time. Including group information, however, would also let us efficient revoke tokens using token revocation events when group membership is affected in any way (user being removed from a group, a group being deleted, or a group-based role assignment being revoked). The OS-FEDERATION extension is actually already including groups in tokens today, as a required part of the federated workflow. We'd effectively be introducing that same behavior into the core Identity API (see the federated token example): *https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token* https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token This would allow us to address bugs such as: *https://bugs.launchpad.net/keystone/+bug/1268751* https://bugs.launchpad.net/keystone/+bug/1268751 In the past, we shied away from including groups if only to avoid bloating the size of PKI tokens any further (but now we have Fernet tokens providing a viable alternative). Are there any other reasons not to add group information to the token validation response? Would the community consider this a useful feature? Would the community consider adding this support to Liberty? Thank you, John
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 wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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@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 exposingX-Group- 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- 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 wrote: On Wed, Jun 3, 2015 at 5:58 PM, John Wood 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 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
