Advance Settings

The following configurations related to Data Encryption Key (DEK) and client secret which can be configured within the Client Manager by clicking on the Advanced Settings tab.

This service allows client applications (e.g. Ascertia SigningHub or any third party application) to use a KEK managed by ADSS Server within its HSM. Note the KEK is only used to encrypt/decrypt Data Encryption keys (DEKs). The DEKs themselves are used directly by the client application to encrypt/decrypt data e.g. SigningHub documents. The benefits of this approach are that client applications do not need to integrate directly with an HSM themselves but can rely on this key management service offered by ADSS Server

The client secret is a secret known only to the business application (e.g. ADSS Signing Service or Go>Sign Mobile SDK) and the authorization server e.g. ADSS RAS Service. The business application provides the client ID and Client secret to the authorisation server for authentication.

Clicking on the Advanced Settings link at the top of the page shows the following screen:

The configuration items are as follows:

Item

Description

Allow this client to access the DEK encryption

Checking this checkbox allows the client to access the DEK encryption/decryption service of ADSS Server.

Key Encryption Key (KEK)

Configure the relevant Key Encryption Key (KEK) which is to be accessible to this client. Note the KEKs are identified in the ADSS Server Key Manager and may have been created in software or HSM.

Client Secret

Generate and configures the client secret for the relevant client by clicking on the generate button.

Once the secret is generated using the generate button, the user need to copy that secret because once user leave this page the client secret will be masked with asterisks for security reason and cannot be copied again.

Redirect URI

It is a Business Application URI where the user will be redirected by RAS Service after authenticating it using OAuth2 mechanism.

If the Allowed Redirect URI(s) list is configured, the default redirect URI specified in the Redirect URI field must also be added to this list for validation. If the default URI is not included in the allowed list, the authorization request will be rejected, and an error will be returned.

Allowed Redirect URI(s)

The Allowed Redirect URI(s) field allows administrators to define a safe and trusted list of redirect URLs that a client application is permitted to use during OAuth 2 authorization.

Redirect URIs are used to send users back to the client application after they complete authentication. To protect against security threats like code hijacking or unauthorized redirects, this field enables the Unity Service to strictly validate redirect URIs.

The below points must be noted for this option:

You can enter multiple full redirect URIs by separating them with a tilde (~) character.
The redirect URI validation is currently applicable only for Unity Service OAuth2 APIs, including:

oauth2/authorize
oauth2/token
oauth2/pushed_authorize
/delegate

Only the listed URIs will be accepted during OAuth2 authorization requests. Any attempt to use a non-listed URI will result in an error.

Behaviour of redirect_uri

The behaviour of the redirect_uri parameter in OAuth2 requests has been updated to improve security and ensure redirection only to authorised URIs.

The Unity Service will now perform validation checks on the redirect_uri parameter based on whether a list of Allowed Redirect URI(s) is configured for the client. The details of these checks are explained below:

If the redirect_uri is included in the request and no list is configured, the Unity Service will allow the redirect URI without any validation.
If the redirect_uri is included and a list of allowed URIs is configured, the Unity Service will check whether the redirect URI matches one of the permitted URIs. If it doesn’t match, the request will be denied, and an error will be returned.
For the OAuth2/token API, if the request includes a redirect_uri, Unity will also verify that it’s part of the allowed list (if one is configured). This adds an extra layer of protection to make sure authorization codes cannot be used with unauthorized redirect URIs.

These changes help prevent attackers from redirecting users to untrusted or harmful locations.