Client Policies
Last updated
Last updated
Within Client Policies, under the Profile section, you can establish a set of executors that are enforced for various actions performed with the client.
These actions may include administrative tasks like creating or updating a client, as well as user actions like authentication to the client.
It refers to the Name of the Client Profile.
It must be unique within the realm.
Enter any concise description that helps you in identifying the purpose of the profile.
This setting can have two values: True and False.
When set to True, it indicates that the Client Profile is pre-configured in ZTrust by default.
These profiles are pre-configured to align with standard security profiles such as FAPI and OAuth 2.1, simplifying the process for administrators to ensure their client applications comply with specific security profiles.
If you've created a new Client Profile, its value under Global would be False.
To create a new Client Profile, click on Create.
On clicking on Create, the following screen will appear.
This denotes the Name of the Client Profile, which must be unique within the realm.
You can select any name that you prefer.
Enter any brief description that helps you in identifying the purpose of the profile.
To create a Client Profile with the specified Name and Description, simply click on Save to apply those details.
You will get the below screen once you click on Save.
Executors determine the action taken on a client that has adopted a client policy.
This includes the Executors that will be enforced for this Client Profile.
To add Executors, click on Create.
Afterward, the subsequent screen will be displayed.
This indicates the type of Executor that you wish to add to this profile.
You can choose the desired option from the dropdown menu.
You can consult the table below to observe the various executors and their functionalities.
confidential-client
At the authorization and token endpoints, this executor verifies if the client is a confidential client. If it is not, the request is denied.
consent-required
When present, registered or updated clients will undergo verification to ensure that the ConsentRequired switch is enabled. Subsequently, they will be automatically configured to have the ConsentRequired switch enabled.
full-scope-disabled
When present, registered or updated clients will undergo verification to ensure that the fullScopeAllowed switch is disabled. Consequently, they will be automatically configured to have the fullScopeAllowed switch disabled.
holder-of-key-enforcer
It prevents clients whose MTLS certificate does not match the certificate thumbprint from accessing tokens.
intent-client-bind-checker
The executor verifies whether the openbanking_intent_id is associated with a client.
pkce-enforcer
It ensures that the client enforces the use of Proof Key for Code Exchange (PKCE) operations with a secure algorithm such as S256.
reject-request
It declines all requests originating from clients.
reject-ropc-grant
It configures ZTrust to decline resource owner password credentials grant requests.
secure-ciba-req-sig-algorithm
The server rejects clients whose signature algorithms are deemed insecure. This is enforced for CIBA backchannel signed authentication requests. It only accepts ES256, ES384, ES512, PS256, PS384, and PS512 algorithms.
secure-ciba-session
To differentiate between authentications corresponding to different CIBA flows, it declines backchannel authentication requests that lack the binding_message parameter.
secure-ciba-signed-authn-req
This executor verifies if the client adheres to the Financial-grade API CIBA Security Profile by including signed authentication in its CIBA backchannel authentication request.
secure-client-authenticator
It ensures that the client enforces the registration or updating of secure client authentication.
secure-client-uris
It prevents clients from registering or specifying URIs with the HTTP scheme.
secure-logout
It mandates specific requirements regarding how clients should handle logout.
secure-request-object
This executor verifies if the client includes the request object in its authorization request in accordance with the Financial-grade API security profile : Read and Write API Security Profile.
secure-response-type
The executor examines whether the client has sent its authorization request with either code id_token or code id_token in its response type, depending on its configuration.
secure-session
secure-signature-algorithm
The server rejects clients whose signature algorithms are deemed insecure. This applies to signing ID Token, Userinfo, and Access Token. Additionally, it is used by the client for the Token endpoint Authentication signature algorithm (for JWT Client Authenticators) and OIDC Request objects. Secure algorithms accepted include ES256, ES384, ES512, PS256, PS384, and PS512.
secure-signature-algorithm-signed-jwt
Clients whose JWT token signature algorithms are deemed insecure are rejected. Secure algorithms accepted include ES256, ES384, ES512, PS256, PS384, and PS512.
suppress-refresh-token-rotation
During token refresh, a refreshed refresh token is not returned to the client.
To save the executor, click on Save.
If you do not want to apply any changes, click on Reset to discard them.
After clicking on Save, the following table will be presented.
It refers to the type of Executor that will be enforced for the Client Profile.
This includes the option you selected from the dropdown menu for Executor Type when creating the Executor.
This includes the available actions that can be taken regarding existing executors, such as Edit or Delete.
If you want to modify any of the attributes within the Executor, click on Edit.
Upon clicking Edit, the following screen will appear.
For example - If you click on Edit for secure-signature-algorithm, the following screen will appear.
This denotes the Executor type you selected during the Executor creation process.
This field cannot be edited.
This describes the preset signature algorithm that will be allocated to clients upon their registration or update if they don't specify any algorithm themselves.
You can modify this setting by selecting your preferred choice from the provided dropdown menu.
Once you've made modifications, click on Save to implement those changes.
After making some adjustments, if you decide not to implement them, simply select Reset to discard those changes.
If you no longer need that specific Executor, click on Delete to remove it.
Upon clicking on Delete, you will be prompted with the following confirmation message.
Choose Delete to proceed with removing the Executor, or click Cancel if you wish to retain it.
If you've made some modifications in the Name or Description field but prefer not to save them, click on Back. This action will redirect you to the screen shown below.
If you click on Back while creating a Profile, the changes you've made won't be saved.
And you'll be directed back to this particular screen.
If you no longer need the Client Profile you created, you can click on Delete to remove it.
This feature will be active only for the Client Profiles you've personally created.
For the default Client Profiles, you will not have the option to delete it.
After clicking on Delete, a confirmation prompt will appear asking for your confirmation.
Click on Delete if you wish to remove the Client Profile, or select Cancel if you want to retain it.
This displays the JSON Editor for the Client Profiles and Executors found in the Form View within the Profiles section.
Within the Policies section, you can link Client Profiles with different conditions to specify precisely when the behavior enforced by Executors of that specific Client Profile is applied.
This refers to the Name of the Client Policy. It is unique within a Realm, without any duplication.
This field helps to identify the purpose of the Client Policy for which it has been created.
This field can be either True or False.
If set to True, it indicates that the Policy is active.
Conversely, if set to False, these policies are completely ignored during the evaluation of Client requests.
It encompasses the available actions that can be taken on the Client Policies, which includes either Edit or Delete.
Click on Edit, if you wish to make any changes to any details regarding the Client Policy.
If the Client Policy is no longer required, click on Delete.
Afterward, a confirmation prompt will be displayed as shown below
Select Delete to remove the specific Client Policy, or click Cancel to retain it.
Upon clicking on Edit, you'll be directed to the screen below.
This pertains to the name of the Client Policy, which can be edited.
However, it must be unique within the Realm.
This field assists in identifying the purpose of the Client Policy for which it has been created, and it can also be modified.
This toggle button shows the status of the Client Policy.
When activated (turned ON), it indicates that the policy is active.
However, when deactivated (turned OFF), these policies are completely ignored during the evaluation of Client requests.
You can modify this field and choose to keep it ON or OFF based on your needs.
To initiate the creation of a new client policy, select Create.
This pertains to the Name of the Client Policy. It should be unique within a Realm, without any duplication.
Enter any description that assists in identifying the purpose of the Client Policy for which you've created the policy.
This toggle button indicates the status of the Client Policy.
When enabled (turned ON), it signifies that the policy is active.
Conversely, when disabled (turned OFF), these policies are disregarded entirely during the evaluation of Client requests.
Once you've filled in the required fields, click on Save to implement those changes.
After clicking on Save, you'll be directed to the following screen.
If you've entered details for the required fields but choose not to save or create the Policy, click on Back. This action will take you back to the screen displayed below.
This pertains to the conditions that will be assessed to decide whether the Client Policy should be applied during a specific action or not.
Click on Create to add a new condition to this Policy.
Upon clicking on Create, you'll be directed to the screen below.
This indicates the type of Condition you wish to apply to this policy.
You can choose the necessary option from the dropdown menu based on your needs.
This toggle button, when enabled (turned ON), reverses the results from the evaluation of the condition from True to False or vice versa.
If deactivated (turned OFF), there is no reversal of results.
You can consult the table below to view the various conditions and their corresponding descriptions.
any-client
This condition applies to any client during any event.
client-access-type
It utilizes the client's access type (confidential, public, bearer-only) to determine the application of the policy. This condition is assessed during the majority of OpenID Connect requests, including Authorization requests, token requests, and introspection endpoint requests.
client-roles
This condition verifies the presence of one of the specified client roles on the client to determine the application of the policy. This enables the client administrator to create a client role with the specified name on the client, ensuring that a specific client policy will be applied to the requests from this client. This condition is evaluated during most OpenID Connect requests, including Authorization requests, token requests, introspection endpoint requests, etc.
client-scopes
It relies on the scopes requested or pre-assigned to the client to determine whether the policy is applied. This condition is assessed during the OpenID Connect authorization request and/or token request.
client-updater-context
The condition examines the context of how the client is created or updated to determine whether the policy is applied.
client-updater-source-groups
The conditions assess the group of the entity attempting to create or update the client to determine whether the policy is applied.
client-updater-source-host
This condition examines the host/domain of the entity attempting to create or update the client to determine whether the policy is applied.
client-updater-source-roles
The condition assesses the role of the entity attempting to create or update the client to determine whether the policy is applied.
If you've entered the necessary details and wish to apply those changes, select Save.
If you prefer not to save your modifications, click on Reset to discard your changes.
If you opt not to create the Condition, selecting Reset will return you to the screen displayed below.
It refers to the type of condition which is applied to this policy.
It lists the various Actions available for this Condition, such as Edit or Delete.
To modify any detail regarding the specific condition, select Edit.
If you no longer require a specific condition, choose Delete to remove it.
Following this action, a confirmation prompt will be displayed as depicted below.
Choose Delete if you want to remove it, otherwise select Cancel.
It lists the Client Profiles that are applied to this Policy.
Click on Add Client Profile and choose the desired option from the dropdown menu.
It will display a list containing all the Client Profiles existing within the Realm.
This refers to the Name of the Client Profile, which is unique within a Realm.
This section provides Actions that can be performed on the Profiles applied to this Policy.
If you want to remove a particular profile applied to this policy, click on Delete.
This displays the JSON Editor for the Client Policies found in the Form View within the Profiles section.
To thwart CSRF attacks, it rejects the client's authorization request if it lacks the parameter in OIDC flow or the state parameter in OAuth2 grant.
