Session quota destroy next expiring session can fail if there are two logins at the same time and they compete to destroy the same next expiring session.
The end user sees MAX_SESSION_REACHED authentication failure and the audit logs indicate the same.
A customer has only seen this occasionally. Its not been reproducible internally but may be possible to simulate using the following:
- Deploy AM, external config and user store (so that CTS is external to AM).
- Login as amadmin, navigate to Configure -> Global Services -> Session, Session Quotas and enable quotas. Leave other settings as defaults, so action is Destroy Next Expiring token, read timeout is 6000. On Dynamic attributes page, max set max number of sessions allowed to 2.
- Login as user demo (to create first session for user) using e.g.: curl -X POST -k -H 'Content-type: application/octet-stream' -H 'X-OpenAM-username: demo' -H 'X-OpenAM-Password: changeit' --header 'Accept-API-Version: protocol=1.0,resource=2.0' 'https://openam.amtest2.com:8443/access/json/authenticate Note the ssoToken returned.
- Repeat the login.
- Using the debugger, set a breakpoint in DestroyNextExpiringAction.action, somewhere in the call stack below line 83 (22.214.171.124) for sessionToRemove = sessionCache.getSession(sessionD); (InMemoryCtsSessionCacheStep.getSessionByID so that the session has been read but the update has not yet been attempted).
- Perform a new login.
- When the above breakpoint is hit, run an ldap command direct to CTS to delete the token about to be read by the first thread.
- Then let the debugger thread continue.
The logic should attempt to remove another expiring session and then return a successful new one for the current authentication.
The authentication fails with MAX_SESSION_REACHED.
The error and stack trace seen when this fails is:
i.e. the logic that performs the getSession looks to also be performing an update (update of expiry perhaps)? This fails because another thread has already deleted the token.