SAML, OAuth and SSO gateways
Sign XPLG console users in through SAML 2.0 or OAuth and OpenID with your identity provider, through SiteMinder or WebSeal web agents, or through a reverse proxy that asserts the user in a header; what each method needs and which configuration pages are still pending.
What you will do: choose the federation or gateway method that matches your identity infrastructure, configure the part the wiki documents, and know where to ask for the rest.
All of these are external realms: the identity provider or gateway authenticates the user — with MFA and conditional access enforced there — and XPLG consumes the assertion, resolves the user to a group and a policy, and never stores federated credentials. Each type is added under PortX > Settings > System Settings > Security > Authentication (the top entry of the Selected Types is the primary) and configured through the link next to it; several can be chained — see Sessions and authentication chaining.
| Method | What it is | Configuration page in the wiki |
|---|---|---|
| SAML 2.0 | Federation with the organisation's identity provider — Entra ID, Okta, ADFS and equivalents | None yet; the method shipped with build 7.9772 (October 2024) — steps pending engineering |
| OAuth / OpenID | Token-based authentication and identity-layer support for modern identity providers | None yet; shipped with 7.9772 (OAuth 2.0) — pending engineering |
| Kerberos | Enterprise authentication protocol at the product layer | None — pending engineering |
| SiteMinder | Native integration with the web-access-management gateway's web agents | Documented below |
| WebSeal | Native integration with the IBM web-access-management gateway | Listed as a type with its own configuration link; field list pending engineering |
| Remote User (header-based SSO) | A reverse proxy or gateway that authenticates the user and asserts the identity in an HTTP header | Documented below |
For a type the wiki does not document, the settings page is reached the same way; the wiki asks you to contact support for authentication types beyond the predefined ones.
Header-based SSO (Remote User)
The XPLG instance must sit behind an HTTP proxy or web agent that is the only entity able to reach it. The proxy authenticates the user against your system (Active Directory, for example) and inserts the authenticated username as a REMOTE_USER header into every request it forwards. XPLG accepts requests carrying the header from a trusted proxy: a user not yet authenticated by XPLG is signed in through a trusted authentication endpoint the process provides; a request without the header gets the login screen.
- Set up the proxy so that it handles authentication itself and adds the header to every forwarded request; most proxy servers are supported.
- In the Remote User settings enter the User header key — one or more header names, comma-separated (
REMOTE_USERby default; XPLG tries them in order) — and the Protected URLs, the trusted authentication endpoints XPLG accepts sign-ins from (comma-separated, wildcards allowed). - Save, and restrict network access to the instance to the proxy, so that nobody can reach it with a forged header; see Networking and ports.
SiteMinder
SiteMinder web agents stand in front of XPLG; users sign in at SiteMinder and are redirected, and XPLG validates the session and reads the user's details from the agent.
| Setting | Meaning |
|---|---|
| User header key | Header names that carry the authenticated user, comma-separated (for example HTTP_SM_USER, HTTP_UID); tried in order |
| Client cookie name | The SiteMinder session cookie (for example SMSESSION) used to validate the user |
| Protected URLs | The protected web-agent URLs XPLG accepts authentication from (comma-separated, wildcards allowed) |
| Group header key | Header names that carry the user's groups, tried in order |
| Group id pattern | A pattern to extract the group value when only part of it is the group |
| User HTTP request key | Request attribute names that carry the user when it is not in a header |
Groups asserted by the gateway are matched to XPLG groups of the same name, like directory groups — see Groups.
Before you go live
- Replace the self-signed certificate: session tracking, integrity validation and enforced HTTPS protect the UI and the API end to end — see TLS certificates.
- A Login URL on the Security tab redirects users to an external validation gateway instead of the built-in login page.
- The audit log records each sign-in with the groups resolved for it; use it to verify the mapping after the first federated sign-in.
- The sign-in to dock is a separate thing with its own SAML and OIDC setup — see Single sign-on (sign in to read).
Next: Sessions and authentication chaining
Source: XPLG wiki, pages 3161718811, 1595408328, 1594133402, 2095611905, 1594133513, 3161489438 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/3161718811). Pending from XPLG engineering: the configuration steps for SAML 2.0, OAuth / OpenID, Kerberos and WebSeal.
