> For the complete documentation index, see [llms.txt](https://ztrust.gitbook.io/ztrust-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ztrust.gitbook.io/ztrust-documentation/user-manual-ztrust-v2.0/guide-to-navigation/realm-settings/client-policies.md). # Client Policies

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. Click the Refresh button to see the latest settings.

You can also choose how many client policies you want to display on one screen. Select your preferred option from the dropdown menu as shown above. You can use the search box to find a specific policy. #### **Name** It refers to the Name of the Client Profile. It must be unique within the realm. #### **Description** It specifies any concise description that helps you in identifying the purpose of the profile. #### **Global** 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, it's not global. If you wish to remove a specific client policy that is no longer necessary, select the Delete option.

Upon clicking Delete, you'll be prompted to confirm your decision.

Choose Delete to proceed with removal, or select Cancel to retain the policy.

To create a new Client Profile, click on Create client profile. On clicking on Create client profile, the following screen will appear.

#### **Client profile name** This denotes the Name of the Client Profile, which must be unique within the realm. You can select any name that you prefer. #### **Description** Enter any brief description that helps you in identifying the purpose of the profile. #### **Save** 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** 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 Add executor. Afterward, the subsequent screen will be displayed.

#### **Executor Type**

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.

Executor Type	Description
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	To thwart CSRF attacks, it rejects the client's authorization request if it lacks the nonce parameter in OIDC flow or the state parameter in OAuth2 grant.
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.

#### **Add** To save the executor, click on Add. #### **Cancel** If you do not want to apply any changes, click on Cancel to discard them. After clicking on Add, the following table will be presented.

#### **Delete** 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 changes but wish to discard them and revert to the previous settings, click on Reload.

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. To initiate the creation of a new client policy, select Create client policy. You will be redirected to the below screen.

#### **Name** This refers to the Name of the Client Policy. It is unique within a Realm, without any duplication. #### **Description** This field helps to identify the purpose of the Client Policy for which it has been created. #### **Save** 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.

#### **Reload** If you've entered details for the required fields but choose not to save, click on Reload. #### **Conditions** 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 Add condition to add a new condition to this Policy. #### **Create** Upon clicking on Add condition, you'll be directed to the screen below.

#### **Condition type**

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. #### **Negative Logic** 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.

Condition Type	Description
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.

#### **Add** If you've entered the necessary details and wish to apply those changes, select Add. #### **Cancel** If you prefer not to save your modifications, click on Cancel to discard your changes. If you opt not to create the Condition, selecting Cancel will return you to the screen displayed below.

Clicking on Add will redirect you to the screen above, with the condition added under the Conditions tab.

#### **Delete** 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. #### **Client Profiles** It lists the Client Profiles that are applied to this Policy.

Click on Add Client Profile and choose the desired option from the menu.

It will display a list containing all the Client Profiles existing within the Realm. #### **Name** This refers to the Name of the Client Profile, which is unique within a Realm. #### **Description** It specifies any concise description that helps you in identifying the purpose of the profile. Click the Refresh button to see the latest settings.

You can also choose how many client profiles you want to display on one screen. Select your preferred option from the dropdown menu as shown above. You can use the search box to find a specific profile. To select a specific client profile, click on the checkbox next to that client profile, then click on Add. You will be redirected to the below screen, with the selected profile added under the Client profiles tab.

If you wish to eliminate a specific profile applied to this policy, select the delete icon. You'll receive a prompt below requesting confirmation.

Choose Delete if you want to remove the profile, otherwise, click Cancel.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ztrust.gitbook.io/ztrust-documentation/user-manual-ztrust-v2.0/guide-to-navigation/realm-settings/client-policies.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.