Digipass S3 is now DigipassONE. This section is currently being updated to reflect our new name.

Federated Identity Management

Prev Next

This v9.5 article is also available in v10.0

Note that there may be additional functionalities discussed in Fed App for federated credential management (v10.0).

External Identity Provider Configuration

The API Server has built-in OIDC client functionality, which is used to access the FIDO credential page nnlfedapp, after a successful OIDC flow with an External IdP. This section tells how to configure the OIDC client functionality with an External Identity Provider (IdP).

When the user tries to access Federated Credential Management Page (nnlfedapp), the correct API Server configuration triggers an OIDC flow to an External IdP where a user can authenticate with an existing authentication method, password for example. Then the user is returned to nnlfedapp, where they can register another credential including a FIDO credential.

Upload a configuration file using the Admin Console. Navigate to Configuration > API Server > Federated Identity Management > External Identity Provider. Then click Add OIDC Provider. A table of mandatory and optional configuration fields is below, followed by two example configurations for client registration JSON files.

The External IdP JSON configuration file can have the following fields:

Field Name

Description

registrationId

Mandatory. String. The registrationId is a unique identifier, within the tenant, for the registration of an OIDC client.

clientId

Mandatory. String. OAuth 2.0 Client identifier which uniquely identifies the client to the IdP server.

clientSecret

Mandatory. String. A secret that proves the authenticity of the Client's requests.

authorizationGrantType

Mandatory. OAuth 2.0 authorization grant type, used to exchange an authorization code for an access token. The only type supported is authorization_code.

clientAuthenticationMethod

Mandatory. The authentication method used when authenticating the client with the authorization server. One of the following standard methods for client authentication:

  • client_secret_basic

  • client_secret_post

responseMode

Optional. Instructs the authorization server how to return the authorization code to the client. Supported values are:

  • query - the code is returned in a URL query parameter. This is the default.

  • form_post - the code is submitted in a form body in a POST request.

scopes

Mandatory. The scope(s) requested during the authorization request flow. You must include the scope openid. You can optionally include additional scopes such as email, profile, address, phone, and so on to get additional user info.

authorizationEndpoint

Optional. URI for the authorization endpoint. If not specified, this is retrieved from the metadata. See issuerUri below for details.

tokenEndpoint

Optional. URI for the token endpoint. If not specified, this is retrieved from the metadata. See issuerUri below for details.

jwkSetUri

Optional. URI for the JSON Web Key (JWK) Set endpoint. If not specified, this is retrieved from the metadata. See issuerUri below for details.

userInfoEndpoint

Optional. URI for the user info endpoint. If not specified, this is retrieved from the metadata. See issuerUri below for details.

redirectUri

Mandatory. The end user is redirected to this endpoint after authentication is completed. The URI must match the predefined pattern: https://<host:port>/nnlfedapp/resp.jsp?reg_id=<registrationId>&tenant_id=<tenantId>

For example: https://example.com/nnlfedapp/resp.jsp?reg_id=regID&tenant_id=default

where regID is the registration ID listed in the first row of this table.

issuerUri

Mandatory. The issuer URI for an OpenID Connect 1.0 Provider. The provider supplies OIDC Provider Metadata for configuration. Refer to OpenID Connect Discovery 1.0 incorporating errata set 2. If any one of these parameters is not provided: authorizationEndpoint, tokenEndpoint, userInfoEndpoint, or jwkSetUri, then the application appends “/.well-known/openid-configuration” to the issuerUri and retrieves the OIDC metadata from that URL to populate the missing configuration endpoints.

clientName

Optional. This is a logical name of the client or registration. If not specified, the registration ID is assigned to clientName.

userNameClaim

Optional. The name of the attribute in the user information response from the external IdP that the API Server uses to identify the end user. When the API Server creates a session JWT, it uses the value of this attribute to obtain the username. For example, if you specify userNameClaim to be email, then the API Server generates its JWT with the user's email address as the username.

The Server first looks for the attribute in the id_token. If it does not find it in id_token then it gets the attribute from UserInfo. If userNameClaim is not specified, then the API Server uses the value of the sub claim from the id_token returned from the IdP.

This parameter was formerly called userNameAttributeName. Both userNameClaim and userNameAttributeName parameters are supported to ensure backward compatibility.

userDisplayNameClaim

Optional. The name of the attribute in the claim received from the external IdP that the client app uses as the user's display name. The value is displayed at the top of the credential management page after Signed in as. If both userDisplayNameClaim and clientUserNameClaim are configured, the Signed in as line displays both values in order to identify both the user and the account they are using.

clientUserNameClaim

Optional. The name of the attribute in the claim received from the external IdP that the client app uses as the username to identify the authenticated user. This username is displayed in the passkey UI and also at the top of the credential management page after Signed in as. If you configure both userDisplayNameClaim and clientUserNameClaim, the Signed in as line displays both values in order to identify both the user and the account they are using. If a user has more than one account on the Server, this username must be different for each account.

This is an example of a client registration JSON that does not use an OpenID Provider to supply metadata. As a result, the configuration must specify the endpoints for authorization, token, user info, and the JWKS.

{
  "registrationId":"pingone_external_idp1",
  "clientId":"f840f954-7b0f-4771-a694-fb6d2fecff28", 
  "clientSecret":"unencrypted_secret",
  "authorizationGrantType":"authorization_code",
  "clientAuthenticationMethod":"client_secret_basic",
  "redirectUri":"https://<host:port>/nnlfedapp/resp.jsp?reg_id=<regID>&tenant_id=<tenantId>",
  "scopes":["openid", "email"],
  "issuerUri":"https://<external-idp-url>/as",
  "authorizationEndpoint":"https://<external-idp-url>/as/authorize",
  "tokenEndpoint":"https://<external-idp-url>/as/token",
  "userInfoEndpoint":"https://<external-idp-url>/as/userinfo",
  "jwkSetUri":"https://<external-idp-url>/as/jwks",
  "userNameAttributeName":"email"
}

An example of a client registration JSON where the OpenID Provider, specified in issuerUri, supplies the configuration metadata.

{
  "registrationId":"pingone_external_idp1",
  "clientId":"f840f954-7b0f-4771-a694-fb6d2fecff28",
  "clientSecret": "unencrypted_secret",
  "authorizationGrantType":"authorization_code",
  "clientAuthenticationMethod":"client_secret_basic",
  "redirectUri":"https://<host:port>/nnlfedapp/resp.jsp?reg_id=<regID>&tenant_id=<tenantId>",
  "scopes":["openid", "email"],
  "issuerUri":"https://<external-idp-url>/as",
  "userNameAttributeName":"email"
}