This topic describes how to use an enterprise identity provider (IdP), such as Okta, Azure AD, or a self-developed system, to log on to the IDaaS EIAM user portal over the OIDC protocol.
Terms
After you bind an OIDC IdP, you can use accounts from Okta, Azure AD, or a self-developed system to log on to IDaaS EIAM.
Term | Description |
OIDC | The OIDC protocol is an upgraded version of the OAuth protocol. It builds a user identity layer on top of OAuth 2.0. For instructions about common configurations, see OIDC SSO configuration. |
IdP | Identity Provider. In this scenario, the IdP is Okta or Azure AD. As defined in the SAML protocol, an IdP authenticates and authorizes users and returns the SAML Response to the SP. The term later generalized to refer to a unified identity management platform. |
SP | Service Provider. In this scenario, the SP is IDaaS EIAM. As defined in the SAML protocol, an SP parses the result returned by the IdP. The term later generalized to refer to an application that integrates with an IdP. |
Federated authentication | Federated Authentication means that the SP trusts and uses the authentication result of the IdP. In this scenario, IDaaS EIAM trusts the authentication results of IdPs such as Okta and Azure AD, which enables logon to IDaaS EIAM accounts. Federated authentication is commonly used to support single sign-on (SSO). |
Bind a generic OIDC IdP
IDaaS EIAM implements federated authentication by using the standard OIDC authorization code flow. In theory, if your IdP, such as Okta, Azure AD, or a self-developed system, supports single sign-on (SSO) with the standard OIDC authorization code flow, it can serve as an IdP for IDaaS EIAM. Users can then use the accounts in that IdP to log on to IDaaS EIAM.
Currently, SSO can be initiated only from the IDaaS EIAM page (SP-initiated). The IdP appears as one of the logon methods on the IDaaS EIAM logon page. Initiating SSO from the IdP (IdP-initiated) is not supported.
Binding a generic OIDC IdP is essentially a process of establishing trust between IDaaS and the IdP. You must obtain and enter configuration information on both sides.
Step 1: Enter basic configurations
Obtain configurations in IDaaS
(1) Go to your IDaaS EIAM instance. In the IdPs menu, click Other IdPs - OIDC IdP to start the binding process.
(2) At the bottom of the form, copy the IDaaS Redirect URI. You enter this URI in your IdP in the second part of this procedure. The URI is used to send authentication requests and ID tokens.
Obtain configurations in your IdP
(1) Create an application that supports the OIDC protocol in your IdP. Set the redirect URI of the application to the IDaaS Redirect URI that you copied in the preceding part.
(2) Obtain the following information and enter it in the IDaaS EIAM form.
Client ID: the identifier that is used to send requests to IDaaS EIAM. This is the identifier of the application in your IdP.
Client Secret: the secret that is used to send requests to IDaaS EIAM. This is the secret of the application in your IdP.
Issuer: the OIDC Issuer discovery endpoint.
(3) In the IDaaS form, click Parse to automatically populate the endpoint information.
(4) Verify the configurations and click Next to go to the scenario selection step.
Step 2: Select a scenario
In the Select Scenario step, you can select the capabilities that you want to use.
Federated Authentication: After this feature is enabled, users can use the OIDC logon method to log on to IDaaS.
Manual Account Binding: After this feature is enabled, when a user logs on to IDaaS by using OIDC, the user can manually verify an IDaaS account by using another logon method if the current OIDC account is not bound to an IDaaS account. After the binding succeeds, the user can use the OIDC account to log on to IDaaS.
Automatic Account Binding: After this feature is enabled, when a user logs on to IDaaS by using OIDC, the accounts can be automatically bound. Automatic binding occurs if the current OIDC account is not bound to an IDaaS account and the IDaaS field and the OIDC account field have the same value. You can click Select Field to directly select a field in the
id_token, or use an expression to customize a field. For more information, see Advanced account field expressions. After the binding succeeds, the user can use the OIDC account to log on to IDaaS.Automatically Create Account: When a user logs on by using OIDC, an IDaaS account is automatically created if the OIDC account is not bound to an IDaaS account. The account information is updated each time the user logs on by using OIDC.
Specified Organization: When a user logs on by using OIDC, IDaaS accounts that do not belong to an organization are automatically assigned to the specified organization. This field is set to the root organization by default. You can search for an organization or select one from the drop-down list.
Automatically Update Information: When a user logs on by using OIDC, the IDaaS account information is automatically updated based on the field mappings.
If you enable both Manual Account Binding and Automatic Account Binding, automatic account binding takes priority. The Automatic Account Binding feature is available only for IDaaS instances of Trial Edition and Enterprise Edition. If you want to use this feature, upgrade your IDaaS instance in advance.
Verify the configurations and click Confirm to create the OIDC IdP.
Step 3: Field mapping (optional)
After you enable Automatically Create Account or Automatically Update Information, the Field Mapping step appears in the creation process.
If an IDaaS account is created by synchronization from another IdP, such as DingTalk or AD, the account data is based on that IdP and cannot be automatically updated here.
After the Automatically Create Account feature is enabled, when a user logs on by using OIDC, the field data in the id_token can be used as the field values of the IDaaS account. This automatically updates the IDaaS account field values. For example, you can use the id_token's name field as the display name of the IDaaS account.
The account logon priority is: bound > automatic binding > manual binding = automatic creation.
If an OIDC account has no binding relationship and cannot be automatically bound, a selection dialog box appears in the logon process. The user can choose to manually bind an account or manually create one.
On the IdPs page, you can delete an OIDC IdP. After deletion, all configurations are immediately removed and cannot be recovered, and the related features become unavailable.