SSO

Single Sign on (SSO) allows you to configure authentication providers for ADOC login. Authentication providers authenticate users and provide them the access to the resources for which they are entitled to.

A user federation is a set of standards and protocols to manage and map user identities between Identity Providers across organizations.

To access the SSO page:

1. Click the Settings icon from the left pane.
2. Click SSO from the Users and Access settings.

In the SSO Authentication window you can configure with the following for Single Sign On (SSO) Authentication types:

1. SSO-Authentications
2. User Federations

SSO-Authentications

Here, you can configure various authentication providers and authenticate users for Single Sign On (SSO). The various that you can configure are as follows:

1. SAML
2. OpenID Connect

SAML

SAML enables the user to access multiple web applications using one set of login credentials. It is an open and cross platform used for directory services authentication.

The following section describes the steps to enable SAML:

1. Click SAML to proceed to the SAML page.

2. Then, upload the SAML XML file provided to your during Okta sign up.

3. Provide the following URLs:

   1. Single Sign On URL : The SSO URL is the endpoint that initiates the authentication process and handles the communication between the identity provider and the service provider (in this case, ADOC).
   2. Auth URL : Auth URL stands for Authentication URL. It refers to the URL or endpoint provided by the identity provider (IdP) where the authentication process takes place. When a user attempts to authenticate, they are redirected to this URL to enter their credentials and verify their identity.

4. Click the Save button to save your changes.

SAML Authentication

OpenID Connect

OpenID Connect is an industry-standard authentication layer built on top of the OAuth 2.0 authorization protocol. The OAuth 2.0 protocol provides security through scoped access tokens, and OIDC provides user authentication and single sign-on (SSO) functionality. It is an open and cross platform used for directory services authentication.

Before configuring OpenIDConnect in ADOC, make sure you have met the following prerequisites:

Prerequisites

For Azure:

1. Create an app registration in Azure.
2. Configure authentication and add a platform in the Azure portal, selecting the web option.
3. Specify the redirect URL by copying it from the ADOC OIDC settings.
4. Enable Access Tokens and ID Tokens.
5. Navigate to Token Configuration and add optional claims for family_name, given_name, and upn.
6. Generate a new client secret in Certificates & Secrets.
7. Keep the client secret, client ID, metadata document URL, and token claims handy for OIDC configuration on ADOC.
   1. Client Secret: This is a key that the ADOC uses to prove its identity when requesting a token. Also referred to as an application password.
   2. Client ID: Known in Azure as the Application ID, this is the unique identifier Azure AD assigns to your application when it's registered.
   3. Metadata Document URL: For Azure, this is the OpenID Connect metadata document URL provided by Azure AD that contains the information required for the client application to perform authentication.
   4. Token Claims: In the context of Azure, these are the user or application attributes and permissions that are packaged into the token issued by Azure AD and used by the application for authentication and authorization.

For Okta:

1. Ensure you have permissions to manage an App Integration in Okta and configure token claims.
2. Create an App Integration with the type Web Application and select the OIDC - OpenID Connect sign-in method.
3. Provide a name for your App Integration and ensure that the Grant Type remains as the default selection, Authorization code.
4. Enter the Sign-In and Sign-Out redirect URLs copied from the ADOC SSO settings.

5. Configure Access Token claims for email, firstName, and lastName by navigating to Security > API in Okta.
6. Copy the Client ID and Client Secret from Okta to be used in ADOC's OIDC settings.

Enabling OIDC

Once the prerequisites are met, follow these steps to enable OpenID Connect (OIDC):

1. OIDC Credentials: Copy your client ID and secret from the identity provider's (IdP) configuration application.
2. OIDC Provider Metadata (Optional): If your IdP offers a metadata endpoint, enter it here. The metadata URL for the OIDC provider automatically fills in the required endpoints for you. To manually input the endpoints, omit this step. For Okta, an example of the metadata URL would be: https://<yourOktaDomain>/oauth2/default/.well-known/openid-configuration.
3. Endpoints and Claims: If you enter the metadata URL in the previous step, Acceldata automatically retrieves all endpoints. If you opted to skip that step, manually input the following endpoint details:

• Authorization Endpoint
• Token Endpoint
• Logout Endpoint
• UserInfo Endpoint (optional)

For Token Claim Mapping, include these details:

Note The character case in token claims matters; if they are lowercase, they must be entered as lowercase.

• Email
• First Name
• Last Name

4. Additional Information (Optional): Specify your Identity Provider's name. This facilitates signing into the ADOC application via your IdP.
5. Review Configuration: Review the configuration details entered in the preceding steps.

Save: Click Save to finalize the configuration.

User Federations

Here, you can configure various user federations to sync users for Single Sign On (SSO). The various that you can configure are as follows:

1. LDAP

LDAP

LDAP is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. It is an open and cross platform used for directory services authentication.

The following section describes the steps to enable LDAP:

1. Click LDAP from the SSO Authentication page.

2. Provide the following inputs:

   1. LDAP URL: This is the URL that specifies the network location of the LDAP server. It includes the protocol (ldap:// or ldaps://) followed by the hostname or IP address and the port number of the LDAP server.
   2. Users DN (Distinguished Name): The Users DN represents the base distinguished name under which user entries are located in the LDAP directory. It specifies the path or location where the user accounts are stored within the LDAP directory structure.
   3. Bind DN (Distinguished Name): The Bind DN is the distinguished name used for authenticating or binding to the LDAP server. It is the username or entry that the LDAP server uses to identify the user who is connecting to the server.
   4. Bind Credential: The Bind Credential is the password or credentials associated with the Bind DN. It is used to authenticate the binding process and establish a connection to the LDAP server.
   5. Username LDAP Attribute: This input specifies the LDAP attribute that contains the username or user identifier. It identifies the attribute in the LDAP directory that corresponds to the username used for authentication and authorization.
   6. RDN LDAP Attribute: RDN stands for Relative Distinguished Name, and this input specifies the LDAP attribute used as the Relative Distinguished Name for user entries. It represents the naming attribute that distinguishes one user entry from another within the LDAP directory.
   7. UUID LDAP Attribute: UUID stands for Universally Unique Identifier, and this input specifies the LDAP attribute that stores a unique identifier for each user entry. It provides a reliable and globally unique identifier for user records, facilitating various operations and ensuring data integrity.
   8. User Object Classes: Object classes define the schema or structure of an LDAP entry. This input specifies the object classes associated with user entries. It determines the set of attributes and properties that can be assigned to a user entry, such as name, email, role, etc.
   9. User LDAP Filter: This input allows you to specify a filter expression to retrieve specific user entries from the LDAP directory. It helps narrow down the search and retrieve only the relevant user records based on certain criteria, such as a specific attribute value or membership in a certain group.

3. Click Test Connection to check the connection.

4. Click Save to save your settings.

Provisioning

SSO Group integration enhances user management with Single Sign-On (SSO) Group Integration using protocols like SAML and OIDC. This feature streamlines user access and provisioning, improving security and convenience within the platform.

Configure Provisioning

Follow these steps to set up provisioning:

1. Click the gear icon to access the settings page.
2. Under User Management and Access, select the SSO option. The SSO Authentication page is displayed.
3. Navigate to the Provisioning tab.
4. Toggle the Enable SCIM button. Once SCIM is enabled, ADOC provides a SCIM URL and token.

5. Copy the provided SCIM URL and token, and incorporate them into your identity provider's (IDP) provisioning credentials

6. Test the connection and save the provisioning settings on the IDP Provisioning page.

After these steps, ADOC lists the users and groups from your IDP on its Provisioning page. In the User Management page, all groups synchronized from the IDP are marked as SCIM Managed.

Note Editing permissions and roles for groups marked as SCIM managed is not possible.

Assign Roles to SCIM Managed Groups

To assign roles to SCIM-managed groups, follow these steps:

1. Click on the name of the group to open the Roles wizard.
2. Select the desired roles.
3. Click Save Roles.