Skip to content
CyberGuardCyberGuard Docs

SSO

Single sign-on lets people reach CyberGuard with the account they already have at your identity provider, so joiners and leavers are handled where they should be — in the directory, not in a second user list. CyberGuard speaks SAML 2.0 and OpenID Connect (OIDC), and one provider is active at a time on an instance.

Where to find it

Section titled “Where to find it”

Extra → Settings → SSO. Administrator rights on the global domain are required. Once SSO is enabled and saved, a Login with SSO button appears on the login page.

The main switches

Section titled “The main switches”
  • Enable SSO — adds SSO as a login option for everyone. Leave the rest of the form disabled until you tick this.
  • Force SSO login — requires SSO for all users and clears saved passwords. Users flagged Exclude from forced SSO keep a password fallback. Confirm SSO works, or keep a fallback account, before you turn this on: there is no way back through the login page if the provider is misconfigured.
  • Enable service provider-initiated single logout — signing out of CyberGuard also closes the session at the identity provider.
  • Provider — pick SAML or OpenID Connect. The form below swaps to match.

SAML settings

Section titled “SAML settings”

Three panels make up a SAML configuration.

SAML IdP configuration takes the IdP Entity ID, then either of two options:

  • Option 1 — fill the Metadata URL. This requires the CyberGuard instance to be able to reach the identity provider over the network.
  • Option 2 — fill the SSO URL (login), the SLO URL (logout) and the x509 certificate by hand, when no such connection exists.

SP configuration holds the SP Entity ID. This is the value your provider calls the Entity ID, Audience URI or Client ID, and it must match on both sides. CyberGuard ships with a default; change it to whatever you registered.

The assertion consumer service (your provider may call it the Reply URL or the Single sign-on URL) is:

<base_url>/api/accounts/saml/0/acs/

Advanced settings cover the attribute mappings (UID, Email, Email verified) and the signing options. Authn request signed is the one most deployments touch: enable it, press Generate to create a key pair, then hand the provider the certificate with Download certificate. You may also paste your own x509 certificate and Private key instead.

OpenID Connect settings

Section titled “OpenID Connect settings”

For OIDC, fill Client ID, Secret and Server URL — the last one points at the provider’s openid-configuration document, from which the endpoints are discovered. Under Advanced settings you can pick a Token auth method and toggle OAuth PKCE enabled, which is recommended. The redirect URI to register at the provider ends in /api/accounts/oidc/<provider id>/login/callback/.

An existing secret is never shown again; the form offers Reset client secret when you need to replace it.

Auto-provisioning (JIT)

Section titled “Auto-provisioning (JIT)”

Turn on the SSO auto-provisioning (JIT) feature flag and the SSO form gains two more fields:

  • Enable auto-provisioning — creates an account automatically the first time a user authenticates through SSO.
  • Default user groups — the groups granted to those new accounts.

Default user groups are applied once, at account creation. Changing or removing the setting later does not touch users who were already provisioned, so plan the starting role carefully — normally a reader-level group on a single domain, with anything more granted deliberately afterwards.

Provider walkthroughs

Section titled “Provider walkthroughs”
Section titled “Related”