Skip to content
GT Arsenals Docs

Enterprise SSO

Enterprise SSO connects Guardian to your own identity provider (Okta, Azure AD, Google Workspace, or any standards-compliant OIDC provider) for centralized sign-in and access control. It’s separate from the “Sign in with Google” / “Sign in with Microsoft” buttons on the login page, which are available on every plan — see Billing & Plans for how the two differ.

There’s no dashboard form for this yet — it’s configured via a direct API call, typically by GT Arsenals support during Enterprise onboarding.

Section titled “OIDC (recommended)”

Requires a superadmin JWT for the tenant (or an operator token, for cross-tenant setup):

Terminal window
curl -X POST "https://your-hub.example.com/api/auth/sso/saml/metadata?tenant=<your-tenant-slug>" \
  -H "Authorization: Bearer <admin-jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "oidc",
    "issuer": "https://your-idp.example.com",
    "entry_point": "https://your-idp.example.com/authorize",
    "token_endpoint": "https://your-idp.example.com/token",
    "userinfo_endpoint": "https://your-idp.example.com/userinfo",
    "client_id": "<client id from your IdP>",
    "client_secret": "<client secret from your IdP>",
    "redirect_url": "https://your-hub.example.com/api/auth/sso/callback",
    "jit_provisioning": true
  }'

Find entry_point (authorization endpoint), token_endpoint, and userinfo_endpoint in your identity provider’s /.well-known/openid-configuration document — every standards-compliant OIDC provider publishes one. All three endpoint URLs are validated server-side (must resolve to a public address, not an internal/private one) when this config is saved.

jit_provisioning: true creates a Guardian account automatically on a user’s first successful SSO login, with the Technician role. Without it, a user must already exist in Users & Roles before they can sign in via SSO.

Once configured, users sign in at /api/auth/sso/login?tenant=<your-tenant-slug>.

SAML

Section titled “SAML”

Requires a superadmin JWT for the tenant, same as OIDC above:

Terminal window
curl -X POST "https://your-hub.example.com/api/auth/sso/saml/metadata?tenant=<your-tenant-slug>" \
  -H "Authorization: Bearer <admin-jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "saml",
    "issuer": "https://your-idp.example.com/entity-id",
    "entry_point": "https://your-idp.example.com/sso",
    "cert": "<IdP signing certificate — base64, no -----BEGIN CERTIFICATE----- header/footer>",
    "jit_provisioning": true
  }'
  • issuer must exactly match your IdP’s Entity ID — Guardian checks the assertion’s Issuer against this value, so a mismatch here always fails closed rather than silently accepting the wrong IdP.
  • cert is the IdP’s own signing certificate (find it on your IdP’s app/integration page — Okta, Entra, and OneLogin all show it as a downloadable .cer/.pem file). Strip the -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- lines — Guardian expects the base64 body only. Internal line breaks in the base64 itself are fine, Guardian strips whitespace before decoding.
  • Get Guardian’s own SP metadata (entity ID, ACS URL) — most IdPs want this to set up their side of the trust — from GET /api/auth/sso/saml/metadata?tenant=<your-tenant-slug> (no auth required, it’s public XML by design, same as any SP metadata document).

Real XML digital-signature verification, not a mock: every assertion’s signature is checked against the certificate above, along with issuer, audience restriction, and expiry — a forged, tampered, or wrongly-signed assertion is rejected before any identity is trusted, with a generic error returned to the browser and the real reason logged server-side for diagnosis.

Both SP-initiated (clicking “Sign in” on Guardian’s login page) and IdP-initiated (clicking your IdP’s app tile) flows work.

Requirements

Section titled “Requirements”

Enterprise SSO is gated by your plan — see Billing & Plans for which tiers include it. Configuring it on a lower tier is refused with a clear error.