You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An admin can create auth tokens for token access for a user. If this user is a user from OIDC/LDAP (e.g. keycloak) and that user is disabled later in the auth server, the auth tokens still remain valid, because the user still has the "enabled" flag in the Graylog Database. There is no sync process which will subsequently remove the enabled flag on the record, regardless of the status of the external account. As a result, an API token belonging to a disabled or deleted user can potentially be used to perform actions.
Compounding this, there is no TTL configuration available right now, so when a token is created it will currently persist until deleted. There is no centralized view in which an administrator can review and manage all of the current active tokens - the Administrator currently needs to navigate to the System > Users > Edit user > Edit Tokens on a per-user basis.
The persistence and difficulty of managing of these tokens represents a bit of a security gap.
Who faces this problem and how important is it to them?
This issue impacts any users with external OIDC/LDAP users that create API tokens.
How do they solve these problems today?
At present, we depend on the vigilance of administrators to manage API token state.
The text was updated successfully, but these errors were encountered:
What problem or job are we going after?
An admin can create auth tokens for token access for a user. If this user is a user from OIDC/LDAP (e.g. keycloak) and that user is disabled later in the auth server, the auth tokens still remain valid, because the user still has the "enabled" flag in the Graylog Database. There is no sync process which will subsequently remove the enabled flag on the record, regardless of the status of the external account. As a result, an API token belonging to a disabled or deleted user can potentially be used to perform actions.
Compounding this, there is no TTL configuration available right now, so when a token is created it will currently persist until deleted. There is no centralized view in which an administrator can review and manage all of the current active tokens - the Administrator currently needs to navigate to the System > Users > Edit user > Edit Tokens on a per-user basis.
The persistence and difficulty of managing of these tokens represents a bit of a security gap.
Who faces this problem and how important is it to them?
This issue impacts any users with external OIDC/LDAP users that create API tokens.
How do they solve these problems today?
At present, we depend on the vigilance of administrators to manage API token state.
The text was updated successfully, but these errors were encountered: