About Entrust as an IDP

Entrust IDP is natively supported by ACP as an OIDC Identity Provider, which means that it has a dedicated connection template in ACP for your convenience. Entrust applications can implement the OIDC protocol, providing the proof of user authentication to ACP within an ID Token and Access Token.

The client authorization flow with ACP connected to Entrust looks as follows:

1. Client app requests the authorization code from ACP.

2. ACP requests the authorization code from Entrust IDP.

3. Entrust authenticates the user and asks for consent to share data with ACP.

4. Entrust issues the code to ACP after user’s authentication.

5. ACP requests tokens from Entrust using the provided code.

6. Entrust issues the tokens to ACP.

7. Optionally, ACP can use the token to pull additional user and group information, but only when the Get user info and Fetch groups option are selected in the connector.

8. ACP asks for user consent to share data with the client app, unless the client app is marked as trusted or the requested scopes were already granted for this app.

9. ACP issues the authorization code to the client app.

10. Client app requests the tokens from ACP.

11. ACP issues the tokens to the client app. ACP tokens are minted based on the incoming Entrust tokens with claims mapped to ACP’s authentication context.

The following steps in the flow are optional:

• ACP only pulls user and group information if these options are explicitly enabled in the Entrust connector configuration, as explained later in this document.
• ACP only asks for consent if the client application is not marked as trusted and requests scopes which were not granted previously (or scopes for which the user’s consent has been withdrawn).

Entrust and SAML

Entrust applications can also use the SAML protocol, but this integration is not natively supported by ACP. If necessary, you can use the generic SAML connector to bind Entrust apps via SAML.

Prerequisites

• You have an Entrust account.

• You have an OAuth application registered in your Entrust domain with the following settings:

  • Grant types supported must include Authorization Code.

  • The following scopes are enabled: openid, email, and profile.

  • If you want ACP to fetch group data from Entrust, add the groups claim to your Entrust application as shown below:

    

Connect Entrust in ACP

Basic configuration

1. In your workspace, go to Identity Data > Identity Providers > Create Identity.

2. Select the Entrust template and click Next.

3. Add the redirect URL from ACP as Login Redirect URI(s) in your Entrust OAuth app.

4. In the Entrust form, enter the required prameters.

   Parameter	Description
   Name	Name for your ACP’s Entrust connection. This name allows users to identify the IDP they need to authenticate with.
   Domain	Entrust domain where the IDP app is registered, similar to example.us.trustedauth.com. Do not include the protocol in the domain.
   Client ID	Client ID of the application registered with Entrust
   Client secret	Secret of the application registered with your Entrust

5. Optionally, enable Authentication context caching.

   Tip

   You can enable the authentication context caching if you wish to store the user’s authentication context locally. If you do, specify the cache Time To Live as well. Learn more by reading Stateful authorization with ACP.

6. Select Save.

   Result

   Your new IDP connection is created and you can now configure the advanced settings if necessary. Users can now authenticate via the OIDC-compliant IDP.

Configure advanced settings

1. From the Identities > YOUR_IDENTITY > Configuration page, select Advanced settings at the bottom.

2. In the Authentication Method Reference, you can select an authentication method to be written into the amr object returned by the IDP. The amr object is created if it doesn’t exist. If it exists, its values are replaced with the selected item.

3. Optionally, enable the Get user info option.

   Note

   If you enable the Get user info option, ACP will call the Entrust userinfo endpoint to retrieve additional user attributes.

4. Optionally, enable the Fetch groups option. If you do, ACP will fetch the user’s group data from Entrust.

5. Select Save.

Entrust ACR to AMR mapping

Entrust IaaS maps the Authentication Context Class Reference (ACR) to Authentication Method Reference (AMR) in a specific way. A SAML URI is written to ACR and then AMR is written based on the ACR value, in accordance with the following rules (acr to the left, amr to the right):

"urn:oasis:names:tc:SAML:2.0:ac:classes:Password" -> "pwd"
"urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken" -> "swk"
"urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract" -> "mfa"
"urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI" -> "sc"
"urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" -> "pwd"

Add custom OIDC IDP attributes

If your IDP returns custom claims outside of the standard OIDC scope, make sure to add them to the IDP connector so that they can be recognized and mapped to the authentication context.

1. Go to Identity Data > Identity Providers and select an IDP from the list.

2. Open the Attributes page. A standard list of OIDC attributes returned by this IDP appears.

3. Select Add attribute. In case of Entrust, the source of data is always the User info endpoint of your Entrust OAuth application.

4. Fill in the form.

   Option	Description
   Claim name	Name of your custom attribute matching the incoming IDP claim
   Display name	User-friendly name for the custom attribute
   Data type	Data type matching that of the incoming IDP claim

   Claim names with a . character

   If the incoming attribute has a . character in the name, the dot must be explicitly escaped using \. when defining the IDP attribute. For example, claim name https://example.com/groups must be entered as https://example\.com/groups.

5. Save your changes and proceed to mapping the attributes to the authentication context.

Map IDP attributes to authentication context

If you’ve added custom attributes for an IDP, you need to make sure they are mapped to the authentication context. You can do it either from the IDP configuration page (as explained here) or use Data Lineage instead.

Default OIDC/SAML attributes are mapped out of the box.

1. Go to Identity Data > Identity Providers and select an IDP from the list.

2. Open the Mappings page. A standard attribute mapping for this IDP appears.

3. Select Add mapping and map any custom IDP attributes to an existing authentication context attribute.

   Note

   If you need to create new authentication context attributes, read Setting up authentication context.

4. Optionally, assign a post-authentication extension to modify your authentication context before issuing the token to the client. Attributes returned by the script do not need to be separately mapped to the authentication context.

5. Save your changes. Your mapped custom attributes should now be shared in the ID token issued to your client application, given that the target application requests them (you can check this in Data Lineage).

Test your Entrust IDP

Prerequisite

Your provider is configured as a user-authentication method by your administrator. Workspace with a demo application is available.

Test

1. Open the user portal.

2. Select LOGIN TO DEMO APP.

3. Select your configured IDP and, next, authenticate in IDP.

Result

ACP displays the consent page that lists data scopes to be shared with the application. When you proceed to the application (ALLOW ACCESS), the PII data coming from IDP is delivered through the access token and the ID token generated by ACP.

Read more

For information on granting and managing ACP consents, see ACP OAuth consents.

Related articles

• Configuring claims for ID tokens and access tokens

• Data lineage

• Setting up authentication context