SAML and OAuth settings

SAML and OAuth Settings

The SAML and OAuth Settings screen is the single control point where your organisation decides how users log in to DPMS — whether through a corporate identity provider (IdP) using SAML 2.0 or OAuth 2.0 instead of, or alongside, local username-and-password accounts. IT administrators come here when connecting a new identity provider such as Microsoft Azure AD, Google Workspace, or Okta; DPOs and risk managers use the read-only view to confirm that SSO is active and properly scoped. Because this screen also contains the toggles that switch on SCIM 2.0 user provisioning and Microsoft Entra ID directory synchronisation, what you configure here ripples across your entire DPMS instance.

How to open it

Navigate to IT Settings → Identity & Access Management → SAML & OAuth in the left-hand sidebar.

You need read access to IT Settings IAM to view the screen. To make changes you also need edit access to IT Settings IAM. If you lack view access, DPMS redirects you to a "403 Forbidden" page instead of showing the screen content.

What you see

The screen opens inside the standard DPMS shell. At the top of the content area you will find a breadcrumb trail reading IT Settings → Identity & Access Management → SAML & OAuth, with each segment acting as a clickable navigation link. Flanking the breadcrumb are left and right chevron arrow buttons that let you move directly to the previous or next section in the IAM menu without going back to the list.

Below the breadcrumb is a single configuration card. Its header shows the section title SAML & OAuth on the left. On the right you will find an Edit button (a pencil icon) and, when an active SSO connection exists, a red Deactivate button. The body of the card displays the current configuration as labelled key–value pairs. Field labels appear in bold blue on the left; values appear on the right. When no configuration has been saved yet, values show a dash. When a SAML or OAuth configuration is active, additional fields become visible — SP metadata URLs for SAML, or client credential fields for OAuth — each accompanied by a small clipboard icon you can click to copy the value.

Working with this screen

Setting up SSO for the first time

When you first arrive at the SAML & OAuth screen, every field shows a dash, indicating no configuration exists yet. Click Edit to open the configuration form.

At the top of the form, a SAML2 / OAuth2 toggle switch lets you choose your protocol. Move it left for SAML 2.0 (common with enterprise identity providers like ADFS, Okta, and Google Workspace SAML apps) or right for OAuth 2.0 / OpenID Connect (common with Microsoft Azure AD app registrations and Google OAuth clients). Your choice controls which set of fields appears below.

Next, select your identity provider from the Configuration Template dropdown: Microsoft, Google, or Custom. Choosing a named template pre-fills the attribute mapping section at the bottom with sensible defaults for that provider, saving you from looking up claim names manually. Selecting Custom leaves all attribute fields blank for manual entry.

For SAML 2.0: After selecting a template, the form shows several read-only SP (Service Provider) fields — SP Entity ID, SP Login URL, SP Logout URL, and SP ACS URL. These are the system-generated values you must copy and paste into your identity provider's enterprise application configuration. Use the clipboard icon next to each field to copy them. Once you have registered those values in your IdP, come back and paste your IdP's Metadata URL into the Identity Provider Metadata URL field, then click the link icon next to it. DPMS will fetch the metadata and automatically fill in the Identity Provider Entity ID, Identity Provider Login URL, Identity Provider Logout URL, and the x.509 certificate. Review those values, type your company's email domain(s) into the Allowed Domains field (for example contoso.com), set an Expiration Date matching your certificate's validity period, and confirm that Sign Messages Enabled is switched on. Click Save. You are returned to the read-only SAML & OAuth overview, which now shows the active configuration.

For OAuth 2.0: After toggling to OAuth2 and selecting a template, fill in your Client ID and Client Secret from your IdP's app registration. If you chose the Microsoft template, also enter your Azure AD Tenant ID. Set an Expiration Date, fill in the attribute mapping section, and click Save.

In both cases, once the configuration is saved, users whose email addresses match the domains you entered in Allowed Domains can log in via SSO on their next visit.

Updating an expiring certificate or client secret

When DPMS or your monitoring system alerts you that a certificate or client secret is about to expire, click Edit on the SAML & OAuth screen.

For a SAML certificate: Scroll to the Identity Provider Certificate text area. You can either paste a new certificate string, paste the URL of the updated metadata (DPMS will extract the certificate automatically), or click Upload Certificate and select a new .pem, .crt, .cer, .der, or .cert file from your computer. After uploading, update the Expiration Date field to reflect the new certificate's validity end date. Click Save to apply the change.

For an OAuth client secret: Be careful here — when you click into the Client Secret field, the stored masked value is immediately cleared and the field enters edit mode. Only click into it if you are ready to type the new secret. Once you have entered the new value, click Save. If you clicked the field by accident and do not enter a new value, simply navigate away using the Back button; the server retains the original secret because the field was not submitted.

Heads up: Clicking the Client Secret field clears the stored value instantly. Do not click it unless you are prepared to enter a replacement secret.

Switching between SAML and OAuth

If your organisation is migrating from one protocol to the other — for example, moving from SAML to OAuth so you can use the Entra ID integration — click Edit, then toggle the SAML2 / OAuth2 switch to the new position. The fields for the previous protocol disappear and the fields for the new protocol appear. Previously entered values for each protocol are remembered separately, so switching back and forth while still on the form will not erase your work.

Fill in all required fields for the new protocol and click Save. Because you are changing an existing saved configuration from one protocol to another, DPMS detects this and displays a confirmation prompt before saving. The prompt warns you that changing the SSO type will affect existing tokens. You have 15 seconds to confirm by clicking the checkmark button in the toast notification. If you do not confirm within that window, the save is silently cancelled — watch for the toast appearing at the bottom of your screen. Once you confirm, DPMS saves the new configuration and deactivates any existing SCIM tokens linked to the old protocol.

Enabling automatic user provisioning (SCIM 2.0)

To let your identity provider automatically create, update, and deactivate DPMS user accounts, scroll to the Enable SCIM2 toggle on the edit form and switch it on. Saving the form with SCIM enabled activates the SCIM Overview sub-page in IAM, where you will find your SCIM base URL and bearer token for configuring your IdP's provisioning connector.

Note that SCIM 2.0 and Entra ID sync are mutually exclusive — enabling one automatically disables the other.

Enabling Microsoft Entra ID directory sync

If you are using the Microsoft OAuth template and want to synchronise users and groups directly from Azure AD rather than using SCIM, enable the Enable Entra ID toggle on the edit form. Saving activates the Active Directory / Entra ID screen in IAM. When Entra ID is enabled, SCIM 2.0 is automatically disabled and the attribute mapping section is hidden, because Entra ID handles group synchronisation on its own.

Deactivating SSO without deleting your configuration

If you need to immediately disable SSO for all users — for example, during a security incident or a planned migration window — return to the read-only SAML & OAuth screen and click the red Deactivate button in the card header. The deactivation takes effect immediately with no confirmation dialog. A success toast confirms the change, and the screen clears all field values. Users who previously logged in via SSO must use their local credentials or another configured method until you re-enable SSO by clicking Edit and saving a new or restored configuration.

Heads up: The Deactivate button acts immediately with no confirmation prompt. SSO will be disabled for all affected users the moment you click it.

Field reference

Configuration Template — Choose Microsoft, Google, or Custom. Pre-fills the attribute mapping section with defaults for the selected provider. Switching templates after entering custom attribute mappings will overwrite those mappings with the new defaults; switching back to the original template restores the previously saved mappings.

Allowed Domains — Comma-separated list of email domains (e.g. contoso.com, subsidiary.com). Only users with email addresses in these domains can authenticate via this SSO configuration. Validated against a domain format pattern; invalid entries will show an error when you attempt to save.

Identity Provider Metadata URL (SAML only) — The URL of your IdP's federation metadata XML file. Paste it and click the link icon; DPMS fetches the document and auto-populates the IdP Entity ID, Login URL, Logout URL, and certificate fields. Values are not saved until you click Save.

Identity Provider Entity ID (SAML only) — The entity identifier URI of your IdP. Auto-populated when you use the Metadata URL feature; can also be entered manually.

Identity Provider Login URL (SAML only) — The SSO endpoint where DPMS sends authentication requests. Auto-populated from metadata or entered manually. Required.

Identity Provider Logout URL (SAML only) — The single logout endpoint. Without this, logging out of DPMS will not trigger a corresponding logout from the IdP.

Identity Provider Certificate (SAML only) — The IdP's x.509 public certificate, used to verify the signature on SAML assertions. Paste the PEM string, paste the certificate URL (DPMS will extract it), or use Upload Certificate to select a certificate file from your computer.

Name ID Format (SAML only) — The SAML Name ID format the SP requests from the IdP. Defaults to persistent. Google typically requires emailAddress. Auto-populated from IdP metadata when available.

Expiration Date — The expiry date of the certificate or client secret. Defaults to one year from today when creating a new configuration. Used as a visible reminder for certificate rotation planning.

Sign Messages Enabled (SAML only, shown when a template is selected) — When on, DPMS digitally signs outgoing SAML requests. On by default; turn off only if your IdP does not support or require signed requests.

Encrypt Name ID Enabled (SAML only, shown when a template is selected) — When on, DPMS encrypts the Name ID in SAML requests. Default varies by template.

Tenant ID (Microsoft OAuth only) — Your Azure AD directory (tenant) GUID, required to construct the correct authentication endpoints.

Client ID — The OAuth application's client identifier issued by your IdP. Required for all OAuth flows.

Client Secret — The OAuth application secret. Displayed as a masked value when already saved. Click into the field only when you intend to replace the secret.

Enable Entra ID (Microsoft OAuth only) — Activates Entra ID directory sync. Mutually exclusive with SCIM 2.0.

Enable SCIM2 — Activates SCIM 2.0 user provisioning. Mutually exclusive with Entra ID.

Group Claims Mapping (Attribute Mapping) — Maps the claim names your IdP sends to DPMS user profile fields. Fields include: unique identifier (OAuth only), name, email, groups, and telephone. Mandatory fields show the placeholder "Mandatory"; optional fields show "Optional". Pre-filled with template defaults; edit if your IdP uses non-standard claim names.

How this connects to the rest of DPMS

The SAML & OAuth screen is the gateway for two major IAM capabilities: federated login and directory synchronisation. Here is how changes here affect other parts of DPMS:

• SCIM Overview (IT Settings → IAM → SCIM Overview): The SCIM sub-page only displays a functional configuration when Enable SCIM2 is switched on here and saved. The Edit button on the SCIM Overview card also leads to this same edit form; after saving from that entry point, you are returned to the SCIM Overview page rather than the SAML & OAuth page.
• Active Directory / Entra ID (IT Settings → IAM → Active Directory): The Entra ID sync feature shown on the Active Directory screen is activated by the Enable Entra ID toggle on this screen. The Edit button on that screen also opens this same edit form.
• Tokens (IT Settings → IAM → Tokens): When you confirm a protocol change (SAML ↔ OAuth), all existing SCIM and IAM tokens are deactivated. Verify your token inventory on the Tokens sub-page after migrating protocols.
• User login: The Allowed Domains list you configure here directly controls which users can authenticate via SSO. A misconfigured or empty list will prevent those users from logging in.
• After finishing this screen: If you enabled SCIM, go to the SCIM Overview page to retrieve the SCIM base URL and bearer token and configure them in your IdP's provisioning settings. If you enabled Entra ID, go to the Active Directory page to complete the Entra ID sync configuration.

Tips & common pitfalls

Tip: Use the Identity Provider Metadata URL field whenever possible. Pasting your IdP's metadata URL and clicking the link icon is far faster and less error-prone than copying individual values one by one from the IdP admin console.

Heads up: The imported metadata values are not saved automatically. After using the metadata URL import feature, you must still click Save before navigating away. If you close the form first, all imported values are lost.

• Attribute mappings are template-aware but not change-safe. If you change the Configuration Template dropdown after customising the attribute mapping fields, the template defaults overwrite your custom entries. The only exception is switching back to the template that was originally saved — in that case, your saved mappings are restored. Always check the attribute mapping section after changing the template.
• The left and right chevron arrows in the breadcrumb let you move sequentially through IAM sub-sections. Use them if you need to jump quickly to Tokens, SCIM Overview, or Roles Mapping after finishing here.
• Changing the SSO protocol triggers a 15-second confirmation toast. If you miss the confirmation window, no changes are saved. Scroll down to watch for the notification when you click Save after switching from SAML to OAuth or vice versa.
• SCIM 2.0 and Entra ID cannot both be active at the same time. The form enforces this by disabling one toggle when the other is switched on. Decide which directory sync approach fits your architecture before configuring this screen.
• The Deactivate button has no undo. Once clicked, SSO is disabled immediately. To re-enable it, click Edit and save the configuration again; the stored values are not deleted by deactivation.

Glossary

SAML 2.0 — An XML-based standard for federated single sign-on. After a successful login at your IdP, the user is redirected back to DPMS with a signed XML assertion confirming their identity.

OAuth 2.0 / OpenID Connect — An authorisation framework and identity layer used by Microsoft Azure AD app registrations and Google OAuth clients. DPMS receives an access token rather than an XML assertion.

Service Provider (SP) — DPMS itself, in the context of SSO. The SP Entity ID, SP Login URL, SP Logout URL, and SP ACS URL are generated by DPMS and must be entered into your IdP's configuration.

Identity Provider (IdP) — The system that authenticates your users, such as Microsoft Azure AD, Google Workspace, Okta, or ADFS.

x.509 Certificate — The IdP's public key certificate, used by DPMS to verify that incoming SAML assertions are genuine and have not been tampered with.

SCIM 2.0 — A REST API standard for automating user provisioning. When enabled, your IdP can create, update, and deactivate DPMS accounts automatically.

Entra ID (Azure Active Directory) — Microsoft's cloud identity service. When the Entra ID toggle is on, DPMS synchronises users and groups directly from Azure AD.

Attribute Mapping — The table that tells DPMS which claim name in a SAML assertion or OAuth token corresponds to each user profile field (name, email, groups, etc.).