User Guide Cancel

Connecting federated authentication to Okta

Last updated on Apr 21, 2022

Welcome to Adobe Acrobat Sign for Government
Administrator processes
1. Admin guide overview
2. Users
3. Users in Multiple Groups (UMG)
  1. Overview
  2. Differences in UMG enabled accounts
Configure your User profile
Support resources
Transaction limits

Connecting Okta to a federated authentication system

Okta allows for other federated identity solutions to maintain the source of truth around their users and function purely as access control for shared applications.

Below are direct links to the Okta documentation for their primary directory integrations.

Note that configuring an external identity solution requires that you have a user in Okta with the appropriate Okta admin authority (configured in the Okta user profile).

Okta also permits external identity providers to be configured.

Log in to the Okta admin console and navigate to Security > Identity Providers > Add Identity Provider to see a list of options:

Note

Notice that a generic SAML 2.0 IdP option exists for any SAML 2.0 compliant identity provider that isn't listed.

Adding the Acrobat Sign Administrative Roles to your directory or IdP configuration

Managing your users via directory or IdP will prevent the option to edit the user profile in the Okta admin console directly.

This means you must customize your identity solution to update the Acrobat Sign admin roles.

Each solution will have differences, but below are a couple of suggestions for some of the more common solutions that may help in your configuration.

Contact your onboarding/professional services team if you need assistance with your particular solution.

LDAP and Active Directory admins can use membership in a group to map the admin roles:

String.stringContains(appuser.group, "signAdmins")? {"Account Admin"} : {} can be used to map the account admins.
String.stringContains(appuser.group, "privacyAdmins")? {"Privacy Admin"} : {} can be used to map the privacy admins.

Configure the SAML 2.0 provider:

All SAML providers will have different interfaces and processes, so the below idea should be understood conceptually and followed to the best of your ability. Contact the Adobe professional services team if you have any trouble or concerns.

We are using OneLogin in this example. Both the SAML provider and the Okta admin console have configuration steps.

Log in to the SAML provider as an Admin
Navigate to Users > Roles

Select New Role
Enter the role name: PRIVACY_ADMIN and select the green checkmark.

Click Save
Click New Role
Enter the role name: ACCOUNT_ADMIN and select the green checkmark.

Click Save
Navigate to Applications > Applications.

Search for your SAML Test Connector (Advanced) App.
Select the Parameters tab and click on the + button (marked with the red circle) to add a new parameter.
Add parameter name: SignRoles.
- Enable Include in SAML Assertion
- Enable Multi-value parameter
- Click Save
In the Default if no value selected field, select User Roles from the drop-down list.

Select Semicolon Delimited input from the next drop-down list.

Click Save.
Click on the Save button in the top right corner.

Configure the Okta admin console:

In Okta the admin console, navigate to Directory > Profile Editor
Select your SAML 2.0 IdP from the list.
In the Profile Editor of your IdP, click on the Add Attribute button.
Configure the attribute as follows:
- Data Type: string array
- Display name: Sign Roles
- Variable name: signRoles
- External name: signRoles
Click Save
In the Profile Editor of your IdP, click on Mappings button.
Select signRoles (appuser.signRoles) from the drop-down list and map it to signRoles in Okta.

Click on the Save Mappings button.

Select Apply Updates now.
In the Profile Editor of your IdP, click on Mappings button (again).
Click on Okta User to SAML 2.0 IdP
Choose signRoles from the drop-down list and map it to signRoles in SAML 2.0 IdP.

Click on the Save Mappings button.

Select Apply Updates now.