Single Sign-On
Single Sign-On (SSO) lets you log into ADOC using your organization’s existing authentication system, instead of managing a separate username and password which is vulnerable to security risks such as weak passwords, reuse, or phishing attacks. Once set up, you sign in once and get access to ADOC resources you’re entitled to, no extra authentication required.
SSO is managed through authentication providers (like Okta, Azure AD) and user federations (systems that sync user identities across platforms).
Accessing SSO Settings
Navigate to the left main navigation menu, click Control Center -> Security -> SSO Authentication. The SSO Authentication page is displayed.
You’ll see two main areas:
SSO Authentications – Connect ADOC to your identity provider for login.
User Federations – Sync and manage user accounts from external directories.
SSO Authentication Options
Prerequisites for SSO Authentication
Before configuring SAML or OpenID Connect (OIDC) in ADOC, ensure that your organization already has a supported Identity Provider (IdP) (such as Okta, Azure AD, Ping Identity, or other SAML/OIDC-compliant systems) set up and managing user authentication.
For SAML, your IdP must be able to provide a valid metadata XML file and endpoints for Single Sign-On and Authentication.
For OIDC, your IdP must support OAuth 2.0 flows and provide client credentials (Client ID and Client Secret), token claims, and metadata endpoints.
You should also confirm that you have administrative access within your IdP to create or configure new application integrations for ADOC.
Without these prerequisites in place, you will not be able to complete the SSO setup in ADOC.
You can set up SSO in ADOC using two industry-standard methods:
1. SAML (Security Assertion Markup Language)
Lets users log in to multiple applications with one set of credentials.
Widely supported and secure.
Example: You log into your company’s Okta portal → you’re automatically signed in to ADOC.
Important
ADOC uses a user's email address as the unique identifier for SCIM provisioning. If your identity provider later sends an updated email for an existing user (for example, after a name change), ADOC does not rename the existing account — it creates a new one instead, which can result in duplicate accounts for the same person. Because most identity providers treat an email change as an update rather than a new-user event, the newly created account typically won't receive its expected group memberships automatically.
To avoid this, standardize the email format used for SCIM provisioning across your organization before you begin, and limit your SCIM attribute mappings to only the required fields. If duplicates do occur, either assign the correct groups to the new account manually, or delete it and re-run SCIM provisioning to recreate it with the correct identity and group memberships.
Setup basics:
From the SSO Authentication page, click SAML.
Upload the SAML XML file provided by your Identity Provider (IdP).
Enter:
Single Sign-On URL – Where ADOC sends login requests.
Auth URL – Where your IdP prompts users for credentials.
Save the configuration.
Service Provider (SP) Details for Your Identity Provider
When registering ADOC as a Service Provider in Azure AD (or another SAML-compliant IdP), your IdP administrator needs the following ADOC endpoint and attribute details to complete the trust configuration:
Parameter | Value |
|---|---|
Identifier (Entity ID) |
|
Reply URL (Assertion Consumer Service) |
|
Logout URL |
|
Name ID Format |
|
Replace <tenant-realm> with your ADOC tenant's realm name.
Attribute & Claims Mapping
Configure your IdP to send the following user attributes in the SAML assertion:
Attribute | Description |
|---|---|
| User's first name |
| User's last name |
| User's email address — required if SCIM provisioning is also enabled |
ADOC functions as the Service Provider (SP); your IdP functions as the Identity Provider (IdP).
Signed AuthnRequests and Assertions are not required.
2. OpenID Connect (OIDC)
Built on top of OAuth 2.0, OIDC adds identity verification on top of secure token-based access.
Example: You log into your Microsoft or Google account, and ADOC recognizes you and signs you in.
Redirect URI for your identity provider
Before you can get a Client ID and Client Secret from your identity provider, you need to register ADOC as an application in it — and every IdP asks for a redirect URI as part of that registration.
From the OIDC configuration page in ADOC, copy the Sign In & Out Redirect URL shown at the top of the page. It's specific to your ADOC tenant and looks like:
https://accounts.acceldata.app/auth/realms/<tenant>/broker/oidc/endpointEnter this as the redirect (or callback) URI when you register the application in your identity provider. Your IdP then gives you back the Client ID and Client Secret you'll need for Step 1 below.
Setup steps
Configuring OIDC in ADOC has five steps.
Step 1: OIDC Credentials
Enter the Client ID and Client Secret from your identity provider's application configuration — the credentials you received after registering ADOC using the redirect URI above.
Field | Description |
|---|---|
Client ID | The identifier your IdP assigned to the ADOC application when you registered it. |
Client Secret | The confidential secret your IdP issued alongside the Client ID. Treat this like a password. |
Step 2: OIDC Provider Metadata (optional)
Most identity providers publish a metadata document that lists their OIDC endpoints in one place. If you provide it, ADOC uses it to fill in the Authorization, Token, and Logout endpoints for you automatically.
Field | Description |
|---|---|
Provider Metadata Endpoint | Your IdP's OpenID configuration URL, typically ending in |
If you don't have this URL, or your IdP doesn't publish one, skip this step and enter the endpoints manually in Step 3.
Step 3: Endpoints & Claims
If you skipped Step 2, enter each endpoint manually here. If you provided a metadata URL, review the auto-filled values.
Field | Description |
|---|---|
Authorization Endpoint | Where ADOC redirects users to log in and grant consent. |
Token Endpoint | Where ADOC exchanges an authorization code for an access token. |
Logout Endpoint | Where ADOC sends users to sign out of your IdP as well as ADOC. |
UserInfo Endpoint (optional) | Where ADOC retrieves additional user profile details after authentication, if your IdP's access token doesn't already include them. |
Access Token is JWT — Turn this on if your IdP's access token is itself a JWT that ADOC can read claims from directly. Turn it off if your IdP issues an opaque access token, so ADOC instead calls the UserInfo endpoint to retrieve claims. [Placeholder: confirm this behavior against the in-product tooltip before publishing — the field has an info icon whose exact wording I don't have.]
Token Claim Mapping — Map ADOC's user attributes to the claim names your IdP's token actually uses. The defaults below follow the standard OIDC claim names; change them only if your IdP uses non-standard names.
ADOC Attribute | Default Token Claim |
|---|---|
| |
First Name |
|
Last Name |
|
Step 4: Additional Information (optional)
Field | Description |
|---|---|
Identity Provider Name (optional) | A display name for this OIDC provider, useful if you configure more than one. Defaults to |
Step 5: Review Configuration
Review every value entered in Steps 1–4 — Client ID, Client Secret (masked), Redirect URI, each endpoint, Identity Provider Name, and the token claim mappings — then select Save.
User Federations (Syncing Users)
User federations connect ADOC to external directories, so you don’t have to manually add or update users.
LDAP (Lightweight Directory Access Protocol)
Used to pull in users from your company’s existing directory service.
Example: If a new employee is added in your corporate directory, they’ll automatically appear in ADOC after sync.
Setup basics:
From the SSO Authentication page, click LDAP.
From the LDAP page, enter the following LDAP server details: URL, Distinguished Names (DNs), Bind credentials, and attribute mappings (username, unique ID, etc.).
Test the connection and save.
Provisioning (SCIM)
Provisioning automates user and group creation in ADOC from your identity provider (IdP).
Example: HR adds a new employee to Okta → they instantly get an ADOC account with the right roles.
Setup basics:
Navigate to the left main navigation menu, click Control Center -> Security -> Provisioning.
From the Provisioning page, enable SCIM (System for Cross-domain Identity Management).
Copy the SCIM URL and token into your IdP’s provisioning configuration.
Test and save.
Groups managed by SCIM can’t have their roles edited directly in ADOC. To change roles, update them in the IdP.
Assigning Roles to SCIM-Managed Groups
Click the Edit icon from the right column the group name table in the Provisioning page.
Provide a name and description for the group.
Select the required roles for the group.
Select domains and map them to required roles. Use the + Add More button to map additional domains and roles.
Click Update to save your changes.
Send a comment