Sessions and authentication chaining

The XPLG console's idle session timeout (30 minutes by default) and how to change it, chaining several authentication types with a defined primary, the custom login URL, automatic lockout after five failed sign-ins, and password rules.

What you will do: set how long a console session may stay idle, in which order authentication types are tried, and what happens on repeated failed sign-ins.

Session timeout

After sign-in, a session with no activity for 30 minutes ends and the user is redirected to the login page; re-authentication is forced. Set the value in minutes under PortX > Settings > System Settings > Security > Session time out. The older procedure edits <session-timeout>30</session-timeout> in ServletContainer/conf/web.xml of the installation directory and restarts the service; prefer the Security tab. Session tracking, integrity validation and enforced HTTPS protect the UI and the API end to end — put your certificate in place first (TLS certificates).

Do not confuse this with the User session timeout interval under Connection Policies: that one closes idle SSH sessions to remote machines XPLG collects from, not console sessions.

Authentication chaining

  1. On the Security tab, under Authentication, move the types you want from Available Types to Selected Types: the internal XpoLog Realm, Active Directory / LDAP, SiteMinder, WebSeal, Remote User (header-based SSO), and SAML 2.0 or OAuth 2.0 since build 7.9772.
  2. Order them: the top entry is the primary authentication type; the others follow.
  3. Open the configuration link next to each type that needs one — see Active Directory and LDAP and SAML, OAuth and SSO gateways.
  4. Optionally set the Login URL to an external validation gateway instead of the built-in login page.
  5. Save.

The internal realm is the documented option for isolated and air-gapped sites; external enterprise authentication is the preferred baseline everywhere else.

Lockout and passwords

  • A user who fails to sign in five times is locked automatically; an administrator unlocks the user on Security > Users (an Unlock link appears on the row) and can lock a user deliberately with Lock Out. See Users.
  • Local-realm passwords are changed by the user under Security > User General Settings and are policy-governed; default credentials must not be used in production.
  • Federated credentials are never stored; MFA for federated users is enforced at the identity provider.
  • Every sign-in, with the groups resolved for it, is written to the audit log; see Diagnostics for the log families.

API and SDK calls

The product's URL API signs in with autoLogin=true&username=…&password=… on the request when security is active, and the SDK takes -user and -password; give integrations a dedicated user with a View-Only or narrowly scoped policy, keep the calls on HTTPS, and see XpoLog search API and SDK and CLI reference.

Next: Getting help

Source: XPLG wiki, pages 1594133402, 3161718811, 1594133481, 1594133426, 1594133410, 1594133390, 1594132942, 1594753063, 1597014018, 2095611905 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/1594133402).