> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/security/session-management.md). # Terminate a user's sessions End one person's live sessions from the screen that can, prove the termination took, and know what it does not reach. ## What this is, and when you need it Somebody has left, or a laptop has been stolen, and you need that person's signed-in browsers to stop working now. One fact changes the shape of this task. **The Webconsole has no screen that lists or ends another person's sessions** — the only session screen in the product is **My Sessions**, and it shows a user their own. What you do have is the account: disabling or locking the identity makes renewal refuse on that user's next request, which ends every live session and closes every future one, and it is audited. For a leaver that is also the right control, because ending a session changes no credential and does not stop the person signing in again. What a session actually is, the two timeouts and what a termination fails to reach are on [What an OpenIAM session is, and what ends one](/administration-guide/security/session-management/session-management-reference.md). ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | The user's live sessions refused at their next request, their OAuth tokens no longer renewable, and the incident evidence recorded from the audit log | | **Where** | The action buttons on the user's record, under **User Admin → User Search**, `/webconsole/users`; the audit log at **Administration → Log Viewer**, `/webconsole/viewAuditLog`. The user's own sessions are on **My Sessions** (`/selfservice/user-sessions`) | | **You need first** | The user's record; an account that can run the **Disable** action on it — the `USER_EDIT_INFO` and `DISABLE_USER` operations, or that user being your subordinate; and the audit search set up before you change anything | | **Takes** | 10–20 minutes for one person. There is no bulk per-user form | | **Reversible** | Partly — re-enabling the identity restores the ability to sign in, but the sessions that were refused in the meantime are gone and nothing reconstructs them | ## Before you begin You do not need a super-administrator account: **Disable** is authorized by the `USER_EDIT_INFO` and `DISABLE_USER` operations, or by the target being your subordinate, on top of the button's own menu grant — [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). Record the evidence before you change anything. There is no retained list of who was signed in, and nothing reconstructs one. The `LOGIN` and `DO_LOGIN` audit events do survive, and they are what you will cite later. ## End one named user's access The worked case: a manager reports that an employee's laptop was taken this morning. The person is still employed and will be issued a replacement machine this afternoon. You want their current sessions gone, their new sessions to work, and evidence afterwards. {% stepper %} {% step %} ### Record the evidence first Search `/webconsole/viewAuditLog` for that user's `LOGIN` and `DO_LOGIN` events over the period in question and attach them to the incident record. Those events carry the IP address and the time of each sign-in, and they are the part that survives what you are about to do. `DO_LOGIN_AGAINST_MANAGED_SYSTEM` is worth including as well: it is how you tell a browser sign-in from an authentication against a managed system. {% endstep %} {% step %} ### Disable or lock the identity Open the user under **User Admin → User Search** and use the action buttons on the record. Renewal re-checks the identity's status on every request and refuses for a disabled or locked user, so the live sessions stop working at each browser's next request, and no new session can be created. This is the only administrative termination the console offers, and it is the one with an audit trail. It is not instantaneous for a browser sitting completely idle — the refusal happens on the next request, not by pushing anything to the browser — but for a leaver or a stolen device it is both sufficient and safer than the alternatives. {% endstep %} {% step %} ### Re-enrol the second factor if the device held one Ending a session does not change a credential. If the laptop held a TOTP secret or a platform authenticator, the second factor travelled with it — clear the enrolment and have the user re-enrol on the new machine. See [Add TOTP as a second factor](/administration-guide/security/totp.md) and [FIDO2 and WebAuthn](/administration-guide/security/fido2-and-webauthn.md#recover-a-lost-replaced-or-compromised-authenticator). {% endstep %} {% step %} ### Re-enable the identity when the replacement machine is ready Reverse the lifecycle action on the same record. The user signs in fresh; nothing carries over from the sessions that were refused. If the laptop is never recovered, leave the identity disabled. Sessions were the emergency; the account is the control. {% endstep %} {% endstepper %} {% hint style="info" %} **If the requirement really is one named session and not the account** — a stuck session, a single compromised browser on a shared machine — the console has no path to it. The user can end their own session from **My Sessions**; for a one-off, anything else is a support request. There are two ESB session operations and they are not interchangeable. The **estate-wide** one takes out every other user and every integration at once and writes no audit record — never reach for it to solve a one-person problem. The **per-user** one is a legitimate route and is audited, but it is built for [an offboarding automation](#terminate-one-users-sessions-from-an-automation) rather than ad-hoc use: calling it by hand means opening a client against an unauthenticated port to do what disabling the account already does, with an audit trail. {% endhint %} ## Verification | What to check | How | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | The identity is really disabled | Re-open the record under **User Admin → User Search** and read the status back. The lifecycle action itself is audited | | Renewal is refusing | *"RenewToken: user status failed for userId = %s"* in the ESB log on that user's next request. This is the line that proves a live session stopped working | | Nothing was missed | `SELECT SESSION_ID, AUTH_STATE, LAST_LOGIN, IP_ADDRESS FROM AUTH_STATE WHERE USER_ID = ''`, read-only. A row still reading `1` is a session record that has not been revoked — expected here, because a disabled user's sessions are refused at renewal rather than revoked, and it is why the status is the control and the row is not | | The user's own view agrees | **My Sessions** (`/selfservice/user-sessions`) for that user reads *"No active sessions found"* once the records are gone | | Audit | `LOGIN`, `DO_LOGIN`, `DO_LOGIN_AGAINST_MANAGED_SYSTEM`, `LOGOUT`, `REVOKE_OAUTH_TOKEN`, `SAML_IDP_PROCESS_LOGOUT_REQUEST`, `SAML_IDP_GLOBAL_LOGOUT`, plus the lifecycle action for the disable itself. See [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) | ## The ways a session ends, narrowest first Prefer the narrowest that achieves the objective. Only the first two are available to you from a screen. | Objective | Do this | Audited | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | End a leaver's access permanently | Disable or lock the user on their record. Renewal then refuses on their next request | Yes, as the lifecycle action | | End one of your own sessions, or have a user end one of theirs | **My Sessions** → revoke | The screen writes a session sign-out; there is no dedicated audit action for it | | End one named session belonging to somebody else | **No console path.** From an automation, [terminate that user's sessions programmatically](#terminate-one-users-sessions-from-an-automation). By hand, disable the account instead | Yes, `LOGOUT` against the target user | | End every session in the estate | **No console path**, and no audited one either. It is an unauthenticated operation on the ESB's own port, with no dry run and no undo — see the two warnings below | **No** | On **My Sessions**, revoking asks *"Are you sure you want to sign out of the selected session?"* and confirms with *"Session signed out successfully"*; revoking the session you are sitting in warns *"This will log you out of this browser"*. {% hint style="warning" %} **The estate-wide clear is a product hazard, not a tool.** It deletes **every unexpired OAuth token in the product** — browser sessions, service-account tokens, integration tokens — and revokes every active session record. There is no dry run, no selection and no undo, and it writes **no audit record**, so nothing afterwards shows that it happened or who did it. Everyone re-authenticates; every machine-to-machine client re-requests a token, and any client that cannot do that unattended stops working until somebody restarts it. The console offers no path to it deliberately. If you believe you need it, treat it as a support request. {% endhint %} {% hint style="danger" %} **One unauthenticated request to the ESB's own port can log out your whole estate.** OpenIAM enforces no authentication on the ESB's session endpoints, and one of them revokes every active session, including yours. Confirm with whoever owns your network that the ESB port is not reachable from anywhere a user is — see the [Installation Guide](/installation/installation.md). The same absence of authentication applies to the per-user operation below, which is why network reachability is the only control on either of them. That the ESB port is closed is a prerequisite for using the per-user route at all, not a separate hardening task. {% endhint %} ## Terminate one user's sessions from an automation The table above says there is no console path to ending somebody else's session. There is a programmatic one, and it is the supported way to fold session termination into an offboarding workflow — ending a leaver's sessions and tokens at the moment their account is disabled, rather than waiting for renewal to refuse on their next request. **`AuthenticationService.globalLogoutRequest` acts on one named user.** Despite the name, it is not the estate-wide clear warned about above: it requires a `userId` and refuses without one, returning `USER_NOT_SET`. | Field | Required | What it does | | ----------- | -------- | -------------------------------------------------------------------------------------------- | | `userId` | Yes | The user whose sessions end. Omitted, the call fails with `USER_NOT_SET` and nothing happens | | `patternId` | Yes | Selects the authentication provider whose logout module runs | | `sessionId` | No | Narrows the operation to one session | | `token` | No | Narrows the operation to the session holding that token | **This route is audited.** It writes a `LOGOUT` event with the target user set — which is exactly what separates it from the estate-wide clear, which writes nothing at all. If you need evidence that an offboarding workflow ended somebody's sessions, this produces it and the estate-wide operation does not. **Token revocation lives alongside it** on `OAuthWebService`, for the OAuth and OIDC tokens a session issued. Ending sessions and revoking tokens are separate operations: a terminated session leaves an unexpired access token usable until it expires on its own. Both services listen on the ESB port — `openiam.esb.port`, which ships as `9080` — and are enabled with no additional configuration. They are built to be called from the Webconsole and IdP components on the same host, so the endpoint is normally reachable only as `localhost`. Confirm the WSDL address against your own deployment rather than assuming the default. {% hint style="danger" %} **Neither service authenticates the caller.** There is no Basic Auth, no WS-Security and no role-based authorization at the SOAP layer — anything that can reach the port can end anyone's sessions. Do not expose it. If an automation has to call these from another host, put your own authentication in front (a reverse proxy requiring credentials, or a firewall allow-list) and connect that host deliberately; do not open the port to a network users sit on. The `LOGOUT` audit event records the target user, **not** who asked for it — so the audit trail tells you what happened and never who did it. {% endhint %} ## See who is signed in **One person, their own sessions.** `/selfservice/user-sessions`, **My Sessions**, shows one user their own active sessions with **Current Session**, **Last Login**, **IP Address**, **Device Info**, **Country** and **City**; the empty state reads *"No active sessions found"*. Country and city are populated only when `org.openiam.adaptive.risk.geo.location.use` is on. **Anybody else, or the estate.** Nothing in the Webconsole answers this. There is no screen that lists another user's active sessions and none that lists every active session, and no audit action is written when the question is asked. What you can see from a screen is the *history*: the `LOGIN` and `DO_LOGIN` events at `/webconsole/viewAuditLog`, with the IP address and time of each sign-in. For live state, the read-only break-glass query below is the only supported answer. {% hint style="warning" %} **Break-glass, read-only: who currently holds a session.** This query bypasses the Webconsole. It changes nothing and is not audited as a read, and its only cost is that you are reading the schema rather than the product's own view of it. There is no screen that answers the question, which is why it is here. {% code overflow="wrap" %} ```sql SELECT a.USER_ID, l.LOGIN, a.SESSION_ID, a.AUTH_STATE, a.LAST_LOGIN, a.IP_ADDRESS FROM AUTH_STATE a LEFT JOIN LOGIN l ON l.USER_ID = a.USER_ID AND l.MANAGED_SYS_ID = '0' WHERE a.AUTH_STATE = 1; ``` {% endcode %} `AUTH_STATE` reading `1` is active and `0` is revoked. A row with no matching `OAUTH_TOKEN` session id is a session whose token has already expired. Do not write to either table: revoking a session by hand leaves the token rows behind and produces exactly the half-signed-out state the **Global Logout** defect produces. {% endhint %} {% hint style="warning" %} **The classic SelfService menu entry ships hidden.** The menu resource `SS_USER_SESSIONS`, display name **My Sessions**, URL `/selfservice/user-sessions`, has been seeded under `SELFCENTER` since 4.2.0.0 with its visible flag set to `N`. The SelfService v2 menu ships its own entry, `SSV2_UM_SESSIONS`, **My Sessions**, visible, as of 2026.6.1.0. If users on the classic SelfService cannot find the screen, the entry is hidden rather than missing — make it visible at `/webconsole/menus` and grant the resource. Menu visibility is not authorization. {% endhint %} ## When it goes wrong | Symptom | Cause | Fix | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A user signs out, the browser looks signed out, and the session record is still active | **Global Logout** is on for that content provider, and that path leaves the session records active. It ships off | Turn `IS_GLOBAL_LOGOUT_SUPPORT` off and report the behaviour to OpenIAM support — [What an OpenIAM session is, and what ends one](/administration-guide/security/session-management/session-management-reference.md#sign-out) | | Everyone logged out at once, no audit record of it | Somebody reached the ESB's session port directly. OpenIAM enforces no authentication on it | Restrict network access to the ESB port — [Installation Guide](/installation/installation.md). There is no audit trail to identify the caller; the gateway or proxy access log is the only place a request would appear | | Revoking a session on **My Sessions** shows *"Security questions could not be reset"* | The session-revoke failure path reuses the security-questions message key; the message text is wrong, the failure is real | Read the UI service log for the actual cause; the message is a product defect, not a clue | | Disabling a user does not sign them out immediately | Renewal is checked on their next request, not pushed to the browser | Expected. A browser sitting idle keeps looking signed in until it asks for something | | Disabled the identity, but the user is still in the federated application | Nothing OpenIAM does sends a logout request to a partner | Expected. Only a browser sign-out chains SAML logout, and only to partners this browser recorded — [What single logout actually reaches](/administration-guide/security/session-management/session-management-reference.md#what-single-logout-actually-reaches) | | Sessions ended, user is straight back in with no prompt | Kerberos or certificate authentication re-establishes silently, and the identity is still enabled | Disable the account; nothing short of that holds this path out | | You want to see another user's live sessions and cannot find the screen | There is none. Only the user's own **My Sessions** exists | Use the `LOGIN` and `DO_LOGIN` audit events for history, or the break-glass query above for live state | | Users are silently signed out under load, without anyone terminating anything | `org.openiam.session.max.concurrent` is above `0` and older sessions are being evicted | Raise it, or set `0` for unlimited. Confirm with *"Max concurrent sessions ({}) reached for user {}"* in the ESB log | | An offboarding automation reports `USER_NOT_SET` and nothing was ended | `globalLogoutRequest` was called without a `userId`. It refuses rather than acting broadly, which is the safe failure | Pass the target user's id. Nothing was terminated, so there is nothing to undo | | The automation's sessions call times out from another host | The ESB port is not reachable from there, which is the intended posture | Run the call from the OpenIAM application server, or connect that host deliberately with your own authentication in front — do not open the port | | Sessions ended for a leaver, but their access token still works | Session termination and token revocation are separate operations | Revoke the tokens through `OAuthWebService` as well; otherwise the token stays usable until it expires | ## Recovery **You disabled the wrong identity.** Reverse the lifecycle action on the record. The user can sign in again immediately; the sessions that were refused in the meantime do not come back, and they do not need to. **Somebody cleared every session and you cannot sign back in.** Sessions are not the reason. If the login page refuses you, the cause is an authentication rule or content provider, and the recovery is the break-glass in [Authentication providers and MFA](/administration-guide/security/authentication-providers-and-mfa.md#keep-a-working-way-in). **Somebody cleared every session and an integration has stopped.** Machine-to-machine tokens went with the rest. Each client has to request a new token; one that only does so at startup needs restarting, which is a deployment action — see the [Installation Guide](/installation/installation.md). ## Related * [What an OpenIAM session is, and what ends one](/administration-guide/security/session-management/session-management-reference.md) — the cookie, the two timeouts, what a termination does not invalidate, and what single logout reaches * [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) — disabling and locking, which is the control this page depends on * [A user cannot sign in](/administration-guide/security/cannot-sign-in.md) — the opposite symptom, when a person who should be able to sign in cannot * [Monitor and maintain OpenIAM](/administration-guide/operations.md) — the other maintenance operations, and the evidence each one leaves *Applies to OpenIAM 2026.8.1. Last reviewed 13 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/security/session-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.