Impacted parties can tune Keystone's behavior in this scenario by reducing their token lifespan (keystone.conf [token] expiration) to match the perceived risk of disabled users & groups continuing to have valid access to OpenStack APIs. This is true regardless of the token format or identity backend in use.
For example, an organization using LDAP concerned that a terminated employee will continue to have access to OpenStack APIs beyond their effective termination date should use a token lifespan of somewhere in the range of 2-24 hours, rather than 7 days, for example.
Keystone already uses a default token expiration value of 3600 seconds (1 hour), which I imagine would be sufficient to mitigate most real world security concerns.
I do not consider this behavior to be a vulnerability and would have assumed it was "well-known tribal knowledge" (sadly undocumented, AFAIK), so +1 for OSSN and a public patch to improve documentation.
Impacted parties can tune Keystone's behavior in this scenario by reducing their token lifespan (keystone.conf [token] expiration) to match the perceived risk of disabled users & groups continuing to have valid access to OpenStack APIs. This is true regardless of the token format or identity backend in use.
For example, an organization using LDAP concerned that a terminated employee will continue to have access to OpenStack APIs beyond their effective termination date should use a token lifespan of somewhere in the range of 2-24 hours, rather than 7 days, for example.
Keystone already uses a default token expiration value of 3600 seconds (1 hour), which I imagine would be sufficient to mitigate most real world security concerns.
I do not consider this behavior to be a vulnerability and would have assumed it was "well-known tribal knowledge" (sadly undocumented, AFAIK), so +1 for OSSN and a public patch to improve documentation.