yahoo-eng-team team mailing list archive

[Jeremy Stanley <2122615@xxxxxxxxxxxxxxxxxx>]

Thanks, based on this discussion I've switched the bug to Public and
marked our security advisory task as Won't Fix for now, treating this as
a hardening opportunity (class D in the VMT's report taxonomy), but
happy to revisit that decision if understanding changes:
https://security.openstack.org/vmt-process.html#report-taxonomy

** Description changed:

- This issue is being treated as a potential security risk under
- embargo. Please do not make any public mention of embargoed
- (private) security vulnerabilities before their coordinated
- publication by the OpenStack Vulnerability Management Team in the
- form of an official OpenStack Security Advisory. This includes
- discussion of the bug or associated fixes in public forums such as
- mailing lists, code review systems and bug trackers. Please also
- avoid private disclosure to other individuals not already approved
- for access to this information, and provide this same reminder to
- those who are made aware of the issue prior to publication. All
- discussion should remain confined to this private bug report, and
- any proposed fixes should be added to the bug as attachments. This
- embargo shall not extend past 2025-12-11 and will be made
- public by or on that date even if no fix is identified.
- 
  When a user is disabled directly from a backend (in our case, we are
  using our own Keycloak backend, but this would happen using LDAP as
  well), their tokens will continue to be active until they expire.  In
  detail:
  
  1. Read-only backends raise Forbidden exceptions on update_user() calls, preventing the revocation event creation code path from executing (https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L1368-L1372)
  2. Without the authenticate() method implementation, there's no trigger point during authentication to detect state changes
  3. External authentication methods only call get_user_by_name() and don't trigger revocation events
  
  Therefore, users disabled in Keycloak/LDAP can continue using existing
  valid tokens until natural expiration, creating a security gap.
  
  I think the solution in this case would be to simply have the revocation
  API lookup the user and check if they're disabled or not.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2122615

Title:
  Tokens not revoked when user is disabled from backend

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When a user is disabled directly from a backend (in our case, we are
  using our own Keycloak backend, but this would happen using LDAP as
  well), their tokens will continue to be active until they expire.  In
  detail:

  1. Read-only backends raise Forbidden exceptions on update_user() calls, preventing the revocation event creation code path from executing (https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L1368-L1372)
  2. Without the authenticate() method implementation, there's no trigger point during authentication to detect state changes
  3. External authentication methods only call get_user_by_name() and don't trigger revocation events

  Therefore, users disabled in Keycloak/LDAP can continue using existing
  valid tokens until natural expiration, creating a security gap.

  I think the solution in this case would be to simply have the
  revocation API lookup the user and check if they're disabled or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2122615/+subscriptions