Skip to main content
Installation

SSO

Analysts sign in with corporate accounts. Caddy reaches the customer IdP through oauth2-proxy, roles come from IdP groups, and the audit trail records the person. An Enterprise feature.

By default the gateway uses its own password login, and accounts are managed on the Users page. Organizations with an IdP use docker-compose.sso.yml instead: the IdP manages accounts, and the gateway stores no passwords. The two modes cannot run together. SSO is an Enterprise feature; if the license does not include it, the gateway ignores the SSO configuration and keeps its own login.

SSO chain

oauth2-proxy is an OIDC reverse proxy. It redirects unauthenticated requests to the IdP and, after sign-in, passes the identity to the gateway in request headers. The gateway trusts those headers on two conditions: it is reachable only through the proxy chain (every /api/* request must carry RST_GATEWAY_SHARED_SECRET), and oauth2-proxy overwrites the headers with the identity verified in its session. Any front proxy that injects identity headers can replace oauth2-proxy, which is how SAML or LDAP can be connected.

SSO decides only who can sign in to the gateway. The gateway still reads and writes QRadar with the same authorized-service token. In QRadar, notes, closes and assignments made through the gateway are recorded under that authorized service; the gateway's Audit log records who did it.

Connect an IdP

Prerequisites

  • An Enterprise license.
  • The oauth2-proxy image quay.io/oauth2-proxy/oauth2-proxy:v7.7.1 on the host. The archive does not include it. On a connected host, pull it when deploy.sh asks; on an air-gapped host, docker pull and docker save it on a connected machine, copy it over and docker load it.

Steps

  1. In the IdP, register a confidential client with the callback URI https://<hostname>/oauth2/callback. Note the client id, client secret and issuer URL.

  2. Run sudo ./deploy.sh, choose 2 for authentication and enter the OIDC issuer, client id and client secret. The script generates the cookie secret and writes the OIDC settings.

  3. Add the role mapping to .env, then run docker compose -f docker-compose.sso.yml up -d:

    RST_RBAC_ADMIN_GROUPS=soc-admins
    RST_RBAC_ANALYST_GROUPS=soc-l1,soc-l2
    RST_RBAC_VIEWER_GROUPS=auditors

The IdP's groups claim travels with the identity. A user in several mapped groups gets the highest role. A user in no mapped group has no role: they can make changes but cannot administer. To enforce read-only access, add their group to RST_RBAC_VIEWER_GROUPS.

For a manual start, leave out --profile bundled-idp; that profile is for the demo environment only.

Settings

SettingDescription
OIDC_ISSUER_URL, OIDC_CLIENT_ID, OIDC_CLIENT_SECRETIdP issuer and client credentials
OAUTH2_PROXY_COOKIE_SECRETSession cookie encryption key, generated by deploy.sh or with openssl rand -base64 32
OAUTH2_PROXY_REDIRECT_URLMust match the callback URI registered in the IdP
OAUTH2_PROXY_SKIP_OIDC_DISCOVERYfalse for a customer IdP, written by deploy.sh
OAUTH2_PROXY_COOKIE_SECURE, OAUTH2_PROXY_REVERSE_PROXYtrue in production, written by deploy.sh
RST_RBAC_ADMIN_GROUPS, RST_RBAC_ANALYST_GROUPS, RST_RBAC_VIEWER_GROUPSComma-separated IdP groups mapped to admin, analyst and read-only
RST_SSO_ENFORCEtrue by default: /api/* requests without an identity get 401
RST_SSO_USER_HEADER, RST_SSO_GROUPS_HEADEROptional. Header names for a different front proxy

Connect Active Directory

For analysts who sign in with AD or LDAP accounts, configure user federation in Keycloak: it checks the account with an LDAP bind at sign-in and hands the identity to oauth2-proxy over OIDC.

Key fields for Microsoft AD: vendor=ad, connectionUrl=ldaps://dc.corp.local:636, usernameLDAPAttribute=sAMAccountName, uuidLDAPAttribute=objectGUID, userObjectClasses=person, organizationalPerson, user, and a service account as bindDn. Add a group-ldap-mapper that maps AD security groups into the groups claim for role mapping.

Demo environment

The bundled-idp profile of docker-compose.sso.yml adds Keycloak and OpenLDAP for demos only. Test accounts are analyst / analyst123 (local Keycloak account) and analyst.ldap / Ldap123! (LDAP federation). Its client secret, redirectUris: ["*"] and sslRequired: none are demo values; use the customer IdP in production.

What changes after sign-in

  • The user field of audit events comes from the SSO identity.
  • The current user appears in the upper-right corner, and sign-out goes through /oauth2/sign_out.
  • The Account page offers no password change; the IdP manages passwords.

On this page