Introduction

Starting from release 2.9.0.0, the 3DS Admin built-in users' authentication (i.e. internal mode of users' authentication) is removed and customers need to use external OIDC provider for authenticating their users.

3DS Admin UI supports the OIDC protocol built on top of OAuth 2. Find more information on it in the official OIDC protocol documentation.

Configuration of the 3DS Admin UI for OIDC

Following OIDC-relevant data for the default organization and the method for resolving the OIDC configuration identifier must be configured for the Admin UI:

The allowed values are header or subdomain. The default value is subdomain, i.e. if not configured otherwise, the OIDC organization identifier will be resolved via the subdomain of the server from which the request originated. Besides that, the OIDC organization can also be resolved via the 'x-nca3dss-orgsubdomain' attribute of the HTTP request header.

Find more information on the properties in the 3DS Admin Configuration Properties.

Different OIDC providers in a multi tenant setup

In a multi tenant setup, different organizations could have different configured OIDC providers. For this purpose, the Organization Management tab in Admin UI is adapted to require the OIDC provider relevant inputs.

In a multi tenant setup, each organization will be accessible on a different subdomain, meaning each organization will have its own URL to access the 3DS Admin. For example, if there is an organization with name Netcetera and a subdomain assigned accordingly (‘netcetera’), then users of this organization can access the 3DS Admin on netcetera.<admin-host>:<admin-port>. The subdomain can differ from the organization name.

Besides a subdomain, the 3DS Admin requires configuring client ID, client secret, an issuer URL and a list of allowed roles for an organization. The client ID and the client secret are the credentials that the client application (the 3DS Admin) is given at the point when it is registered to the OIDC provider, while the issuer URL is a URL that uniquely identifies the OIDC provider and has to comply with OpenID Connect 1.0. The issuer URL should begin with https:// and contain a valid domain name without any IP addresses, port specifications, or URL parameters. The hostname cannot contain '@'.

Finally, the 3DS Admin controls what roles can be assigned to users of this organization and for that purpose there is input for allowed roles.

User management with external OIDC provider

Any OIDC provider can be chosen. The management of the OIDC provider and the users’ data management is left to the customer.

3DS Admin role based access control

The 3DS Admin allows the following roles to be assigned to a user:

• ROLE_CONFIG_GENERAL_EDIT
• ROLE_CONFIG_SCHEME_VIEW
• ROLE_CONFIG_SCHEME_EDIT
• ROLE_CONFIG_ACQUIRER_VIEW
• ROLE_CONFIG_ACQUIRER_EDIT
• ROLE_CONFIG_MERCHANT_VIEW
• ROLE_CONFIG_MERCHANT_EDIT
• ROLE_KEY_MANAGEMENT_VIEW
• ROLE_KEY_MANAGEMENT_EDIT
• ROLE_TRANSACTION_SEARCH
• AUTH_ADMIN
• AUTH_SUPER_ADMIN

The explanation of each is given on the picture below:

If any other role is assigned to a user, the 3DS Admin will ignore it. The 3DS Admin also controls what roles are allowed per organization. If a user from a certain organization is assigned with a role which is not allowed by the organization configuration, the 3DS Admin will ignore that role.

The OIDC provider has to be configured to return the user roles in a custom claim inside the ID token. The name of the claim can be configured via the threedss.external-iam.default-organization-oidc-provider.roles_claim_name property.

Health status of the external OIDC providers

The 3DS Admin gives information about the health of the configured OIDC providers through the standard health endpoint. The health of the OIDC providers does not affect the overall health status, meaning some OIDC providers can be down but the overall 3DS Admin health stays up.