Cassandra RBAC and External Identity Providers: Credential Expiration Interoperability

Credential Expiration and Session Persistence

The PasswordAuthenticator interface in Apache Cassandra does not provide a native callback mechanism to trigger the invalidation of active session tokens upon external credential expiration. Authentication is a point-in-time event; once a user is authenticated via an external provider (such as LDAP or Kerberos), the resulting session is maintained by Cassandra independently of the external provider's state.

Expected Behavior for Active Sessions

When credentials are revoked or expire in an external identity provider, the behavior for existing active sessions is as follows:

• Existing Connections: Active CQL sessions typically remain open. Cassandra does not continuously poll the external provider to verify the validity of a session after the initial handshake.
• New Connections: Any attempt to establish a new connection will fail, as the external provider will reject the credentials during the authentication phase.
• Internal RBAC: Permissions stored in the system_auth keyspace remain active. The RBAC system only checks if the authenticated role has the required permissions; it does not verify if the external identity that granted that role is still valid in real-time.

Implementation Considerations

To achieve stricter interoperability between an external provider and Cassandra's internal RBAC, consider these scoped approaches:

1. Session Timeouts: Reduce the connection timeout settings to force more frequent re-authentication events.
2. Custom Authenticator: Implement a custom IAuthenticator that incorporates a time-to-live (TTL) for authenticated sessions, forcing a re-check against the external provider at defined intervals.
3. External Orchestration: Use an external automation script to execute REVOKE or DROP ROLE commands in Cassandra when a user is deactivated in the identity provider.

Verification Steps

To verify the persistence of sessions in your specific environment, you can use the following test pattern:

# 1. Establish a session via cqlsh
cqlsh -u username -p password

# 2. Expire or disable the user in the external LDAP/Kerberos provider
# (Perform this action in your IDP management console)

# 3. Execute a query in the existing cqlsh session
SELECT * FROM system.local;

# 4. Attempt to open a second, new cqlsh session
cqlsh -u username -p password

If Step 3 succeeds while Step 4 fails, your environment is exhibiting standard session persistence behavior.

Diagnostic Detail Needed: Are you using a third-party commercial distribution of Cassandra (e.g., DataStax) or the open-source Apache Cassandra project? Commercial versions often include proprietary authenticators with different session management capabilities.