Skip to content

Session Audits

Ranger generates a session audit event on every login attempt and every session refresh — whether the request originates from the Privacera Portal or from a client calling the Ranger REST API directly. These events capture who attempted to authenticate, when, from which IP address, whether the attempt succeeded or failed, and how the user authenticated. Session audits are the primary source of truth for login activity and are essential for security monitoring, compliance reporting, and incident investigation.

Routine authenticated API calls that do not trigger a login or session refresh do not produce session audit events.

What Triggers a Session Audit

Trigger action value
A new login is detected (no matching session exists) CREATE
An existing session is refreshed (session already exists) UPDATE

Accessing Session Audits

Session audits can be viewed in the Privacera Portal under the Login Sessions tab.

Session Audit Fields

Field Description
Event ID Unique UUID assigned to this audit event at the moment it is emitted. Used as the document primary key in Solr and S3.
Login ID Username submitted at login. This is the raw value from the login form or HTTP header and may differ in casing from the stored Ranger user record.
Auth Status Outcome of the login attempt. See Authentication Status values below.
Auth Type Mechanism used to authenticate. See Authentication Type values below.
Auth Provider Identity provider that verified the credentials. See Authentication Provider values below.
Device Type Category of the client device, derived from the User-Agent header. See Device Type values below.
Request IP IP address of the client that initiated the login. When Privacera is behind a reverse proxy, this reflects the address seen by the application server.
Auth Time Timestamp of the authentication attempt as recorded in the database. Always slightly earlier than the event emission time.
Event Time Wall-clock timestamp captured at the moment the audit event is built and emitted — a few milliseconds after authTime.
Action Whether the session row was CREATEd (new login) or UPDATEd (session refresh).
DB Record ID Primary key of the underlying x_auth_sess database row, providing a direct link between the audit event and the database record.
User ID Internal Privacera user ID. null for failed login attempts where the username was not found.
Session Token HTTP/Spring session token assigned by the server after a successful login. null for non-interactive logins (for example, API clients).
Tenant ID Multi-tenant deployment identifier. Empty in single-tenant installations.

Authentication Status

Value Meaning
0 — Unknown Status could not be determined
1 — Success Login succeeded
2 — Wrong Password Credentials were incorrect
3 — Disabled The account has been disabled
4 — Locked The account is locked after too many failed attempts
5 — Password Expired The user's password has expired
6 — User Not Found No Ranger user matches the submitted username

Authentication Type

Value Meaning
0 — Unknown Authentication mechanism could not be determined
1 — Password Username and password form login
2 — Kerberos Kerberos ticket
3 — SSO Single Sign-On (SAML, OAuth, etc.)
4 — Trusted Proxy Pre-authenticated header from a trusted upstream proxy

Authentication Provider

Value Meaning
0 — Unknown No specific provider configured (default in single-provider setups)
1 — Password Internal Ranger/Privacera password store
2 — Kerberos Kerberos KDC
3 — SSO External SSO provider
4 — Trusted Proxy Upstream trusted proxy

Device Type

Derived from the User-Agent header at login time. The raw User-Agent string is not stored in the audit event.

Value Meaning
0 — Unknown Device type could not be determined
1 — Browser Desktop or mobile browser
2 — iPhone iPhone
3 — iPad iPad
4 — iPod iPod
5 — Android Android device

Sample Session Audit Event

The following is an example of a session audit event as it appears in S3 and in the Audit Server's HTTP delivery pipeline.

JSON
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
{
  "auditType":    "__session_audit__",
  "id":           "3f2a1b4c-8e9d-4f7a-b2c1-0d5e6f7a8b9c",
  "tenantId":     "17775610850011",
  "evtTime":      "2026-05-04T13:09:00.607+0000",
  "event_count":  1,
  "event_dur_ms": 0,
  "dbId":         42,
  "loginId":      "blue.sky",
  "userId":       6,
  "extSessionId": "AF8C2BC20BA4B3811DD4186DD3CF6BBF",
  "authTime":     "2026-05-04T13:09:00.598+0000",
  "authStatus":   1,
  "authType":     1,
  "authProvider": 0,
  "deviceType":   1,
  "requestIP":    "10.227.53.251",
  "action":       "CREATE"
}

In this example:

  • User blue.sky logged in successfully (authStatus: 1) using a username and password (authType: 1) from a browser (deviceType: 1).
  • The login originated from IP 10.227.53.251.
  • A new session row was created (action: CREATE) with database ID 42.
  • The session token issued is AF8C2BC20BA4B3811DD4186DD3CF6BBF.

User-Agent not stored

The raw User-Agent header string is intentionally excluded from session audit events to avoid bloating audit payloads — strings up to 1,024 characters per login add up quickly at scale. The deviceType field provides a condensed categorical equivalent.