Federated identity login does not prevent disabling account due to inactivity

[Daniel Leehr]

On keystone configured with OIDC federated login and disable_user_account_days_inactive, accounts become disabled after the specified number of days even if users regularly access accounts with OIDC login. OIDC login does not count as activity, nor does token authentication. It seems direct authentication with username/password is expected for activity.

From a review of the source, it appears there are 2 cases where keystone updates last_active_at in the database.

The first is authenticating with a password: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L900-L908

The second is when a federated (e.g. OIDC) login happens for an ephemeral user: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L1486-L1512

We use federated users but we map them to existing local keystone users in the default domain - so they're not ephemeral.

To confirm, I switched our mapping to ephemeral. With mapping set to ephemeral, logging into OIDC does update the last_active_at field, but it creates a second user account in a separate domain, and this is not our use case.

[Daniel Leehr (danleehr)]

Relevant part of the docs: https://docs.openstack.org/keystone/ocata/security_compliance.html#disabling-inactive-users

> PCI-DSS 8.1.4 requires that inactive user accounts be removed or disabled within 90 days
> This above example means that users that have not authenticated (inactive) for the past 90 days
> will be automatically disabled. Users can be re-enabled by explicitly setting the enable user
> attribute via the API.

Difficult to build a workaround to find why an account is inactive because the last_active_at field is only stored in the database. it is explicitly hidden from API objects, including unit tests to ensure it does not appear: https://github.com/openstack/keystone/blob/07abf2fa4d5c2bc5dc1c77d700ac3589d1169d3f/keystone/tests/unit/test_v3_identity.py#L297-L303.

Without digging into internals, we can't readily tell the difference between an account disabled due to this bug or one disabled administratively

[Walter (wdoekes)]

https://review.opendev.org/c/openstack/keystone/+/712724

I thought this was fixed already, so I had completely forgotten about it.

[Daniel Leehr (danleehr)]

Thank you for the comment and link to the change. What's the status of the fix - is it going to be merged?