Clients
Last updated
Last updated
It pertains to the ID referenced in URIs and tokens.
It can be set to either True or False.
When set to True, the client is permitted to perform certain actions.
Conversely, when set to False, the client is deactivated and cannot initiate logins or obtain Access Tokens.
This value is added to the beginning of the URL when ZTrust uses a configured relative URL.
It encompasses the available actions that can be performed on clients, such as Edit, Export or Delete.
If you want to modify specific settings for a particular client, select Edit.
If you want to download all the settings and information for a client, click on Export.
Afterward, a JSON file will be downloaded containing all the information associated with this specific client.
If you want to remove the client, choose Delete.
Upon selecting Delete, a confirmation prompt will appear as shown below
If you wish to proceed with deleting the client, click Delete; otherwise, click Cancel.
If you want to create a new client, simply click on Create.
Upon doing so, you will be directed to the following screen.
If you want to import information related to a client from a specific file, use the Select file button next to the Import feature.
This allows you to upload a file containing all the relevant client information.
This field is crucial as it is referenced in URIs and tokens.
It's mandatory when configuring a client.
In the case of SAML, it represents the expected issuer value from authentication requests.
This indicates the protocol utilized for authentication or authorization for this specific client.
You can adjust this setting and choose between two options -
OpenID Connect: This enables clients to verify the identity of the End-User based on authentication conducted by an Authorization Server.
SAML (Security Assertion Markup Language): This facilitates web-based authentication and authorization scenarios, including cross-domain single sign-on (SSO), and utilizes security tokens containing assertions to transmit information.
This value is added to the beginning of the URL when ZTrust uses a configured relative URL.
If you want to proceed and create the client with the specified settings, click on Save after making the changes.
If you want to discard the mentioned specifications and not create a client, click on Reset.
Upon clicking on Save, you will be presented with the following screen.
Under the Settings tab, you can configure the various configurations related to Clients.
This specifies the ID that is referenced in URIs and tokens.
This refers to the display name of the client.
It can be customized, allowing you to set any name according to your needs.
This pertains to the description for the Client.
You can establish any description that helps you identify the client effectively.
This toggle button determines whether this specific client is allowed to initiate login or obtain Access Tokens.
When enabled (turned ON), the client can perform these actions.
Conversely, when disabled (turned OFF), the client is deactivated and cannot initiate login or obtain Access Tokens.
You can adjust the toggle button according to your preferences.
This toggle button controls whether the particular client is always listed in the Account Console, even if the user doesn't have an active session.
When enabled (turned ON), the client is always displayed.
However, when disabled (turned OFF), the client is not listed continuously.
You can adjust this setting based on your needs.
This toggle button determines whether users are required to consent to client access.
When enabled (turned ON), users must provide consent.
Conversely, when disabled (turned OFF), users are not required to give consent.
You can adjust this setting according to your preferences.
The dropdown provides different theme options for the login page, including OTP Entry, New User Registration, and the Login screen for the specific client.
You can customize this field and select the desired theme according to your preferences.
This indicates the protocol utilized for authentication or authorization for this specific client.
You can adjust this setting and choose between two options -
OpenID Connect: This enables clients to verify the identity of the End-User based on authentication conducted by an Authorization Server.
SAML (Security Assertion Markup Language): This facilitates web-based authentication and authorization scenarios, including cross-domain single sign-on (SSO), and utilizes security tokens containing assertions to transmit information.
This field can be customized according to your needs.
If the Access Type is set to Confidential, the client necessitates a secret to initiate the login protocol. Conversely, if the Access Type is Public, clients do not require a secret.
If it is set to bearer-only, the clients are web services that never initiate a login.
This toggle button, when activated (turned ON), enables standard OpenID Connect redirect-based authentication with authorization code.
In terms of OpenID Connect or OAuth2 specifications, this facilitates support for Authorization Code Flow for this client.
If deactivated (turned OFF), this specific flow is not enabled for this client.
You can customize this setting according to your specific requirements.
Once enabled, it also triggers the activation of two additional fields: Valid Redirect URIs and Valid Post-Logout Redirect URIs.
When activated (turned ON), this toggle button enables standard OpenID Connect redirect-based authentication without authorization code.
In the context of OpenID Connect or OAuth2 specifications, it supports the Implicit Flow for this client.
If deactivated (turned OFF), this specific flow is not enabled for this client.
You can customize this setting according to your requirements.
When enabled (turned ON), this toggle button allows support for Direct Access Grants, granting the client access to the username/password of the user and exchanging it directly with the Keycloak server for an Access Token.
In terms of OAuth2 specifications, this enables support for the Resource Owner Password Credentials Grant for this client.
If turned OFF, this specific flow is not enabled.
You can adjust this setting according to your requirements.
When activated (turned ON), this toggle button enables support for OAuth 2.0 Device Authorization Grant. This means that the client is an application on a device with limited input capabilities or lacks a suitable browser.
If turned OFF, this feature is not enabled.
You can customize this setting according to your requirements.
This toggle button, when activated (turned ON), mandates a browser redirect to the client for logout. When deactivated (turned OFF), the server executes a background invocation for logout.
You can adjust these settings based on your needs.
Once enabled, two additional fields are also activated: Front-Channel Logout URL and Front-Channel Logout Session Required.
This field specifies the URL that prompts the client to log itself out when a logout request is sent to this realm via the end_session_endpoint.
If not provided, it defaults to the base URL.
This field is customizable, allowing you to modify it as needed.
When activated (turned ON), this toggle button ensures that the SID (Session ID) and ISS (Issuer) claims are included in the Logout Token when the Front Channel Logout URL is utilized.
If deactivated (turned OFF), these claims are excluded.
You can tailor this setting to suit your requirements.
This value is added to the beginning of the URL when ZTrust uses a configured relative URL.
This refers to the valid URI pattern to which a browser can redirect after a successful login or logout. Enter the desired URI Pattern and click on the '+' symbol to add it.
You can select the '-' symbol if you wish to remove a particular URI pattern.
This pertains to the valid URI pattern to which a browser can redirect after a successful logout.
Enter the desired URI pattern and click on the '+' symbol to add it.
You can select the '-' symbol if you wish to remove a particular URI pattern.
This denotes the default URL that the authentication server has to use when redirecting or linking back to the client.
This is the URL to the Admin interface of the client.
This URL references a logo for the Client application.
This indicates the URL provided by the Relying Party Client to the End User for reading about how the profile data will be used.
You can set it up according to your needs.
This field specifies the URL provided by the Relying Party Client to the End-User for reading about the Relying Party’s terms of service.
You can customize it according to your requirements.
The domain URLs listed here are included in the access token sent to the client application. The client application utilizes this data to determine whether to permit a CORS request to be initiated.
You can input any domain URL and click on the '+' symbol to add it.
If you wish to remove a specific URL, you can select the '-' symbol.
This field specifies the URL that triggers the client to log out when a logout request is sent to the realm via the end_session_endpoint.
If omitted, no logout requests will be sent to the client in this scenario.
You can modify it according to your requirements.
It is a toggle button, when activated (turned ON), adds the Session ID claim to the Logout Token sent via the Backchannel Logout URL.
When deactivated (turned OFF), the SID isn't included.
You're free to customize this according to your needs.
This toggle button, when activated (turned ON), adds the revoke_offline_acccess event to the Logout Token sent via the Backchannel Logout URL. ZTrust will then revoke offline sessions upon receiving a Logout Token with this event.
When deactivated (turned OFF), this specific event isn't included in the Logout Token.
You can customize this setting according to your needs.
Within the Fine Grain OpenID Connect Configuration, you have the ability to adjust the following client settings that pertain to the OpenID Connect protocol.
This pertains to the JWA algorithm utilized for signing the Access Token.
It's a customizable field where you can choose the preferred option from the dropdown menu based on your needs.
This describes the JWA Algorithm utilized to sign the ID Tokens.
It's a customizable field where you can select your preferred option from the dropdown menu to suit your requirements.
This refers to the JWA Algorithm employed for key management in encrypting ID Tokens.
Selecting an option from the dropdown menu is necessary if you require encrypted ID Tokens.
You can choose the preferred algorithm based on your needs.
If left blank, ID Tokens will only be signed without encryption.
This indicates the JWA Algorithm utilized for content encryption when encrypting ID Tokens.
Selecting an option from the dropdown menu is necessary if you desire encrypted ID Tokens.
You can pick the preferred algorithm according to your requirements.
If left unspecified, ID Tokens will only be signed without encryption.
It refers to the JWA Algorithm that is used for signed User Info endpoint response.
If set to unsigned, the User Info response won't be signed and will be returned in application/json format.
This setting is adjustable, allowing you to choose your preferred response format from the dropdown menu.
This pertains to the JWA Algorithm utilized for managing keys in the encryption of User Info Endpoint responses.
Enabling this option is necessary if you desire encrypted User Info Endpoint responses.
If left blank, these responses remain unencrypted.
This field is customizable and can be adjusted based on your needs.
This refers to the JWA Algorithm utilized for encrypting the content of User Info Endpoint responses.
If the algorithm for key management in User Info Response Encryption is not specified, the default value is A128CBC-HS256.
You have the flexibility to choose the most suitable option according to your needs.
This is about the JWA Algorithm utilized by clients when sending OIDC request object specified by 'request' or 'request_uri' parameters.
When set to 'any', the request object can be signed by any algorithm, including 'None'.
You can choose any option from the dropdown menu based on your preferences.
This refers to the JWE Algorithm that clients must use when sending OIDC request object specified by the 'request' and 'request_uri' parameters.
If set to 'any', encryption becomes optional and any algorithm is permitted.
You can select the most suitable option from the dropdown menu according to your needs.
This describes the JWE algorithm that clients are required to utilize when encrypting the content of the OIDC request object specified by the 'request' or 'request_uri' parameters.
If designated as 'any', any algorithm is permitted.
You have the flexibility to choose the most appropriate option from the dropdown menu to suit your needs.
This setting determines whether clients are needed to include a request object with their authorization requests and the method they employ for this purpose.
When set to 'not required', providing a request object is optional. Otherwise, in all other scenarios, providing a request object is mandatory.
If set to 'request only', the request object must be specified directly.
If set to 'request_uri only', the request object must be provided by reference.
Alternatively, if set to 'request or request_uri', either method can be used.
This field is adjustable, allowing you to select the most appropriate option according to your needs.
This pertains to the list of acceptable URIs that can be utilized as values for the 'request_uri' parameter during an OpenID Connect authentication request.
To add a Valid Request URI, input it and then click on the '+' symbol.
If you wish to remove a specific Request URI, simply click on the '-' symbol to delete it.
This refers to the JWA Algorithm utilized for signing authorization response tokens when the response mode is JWT.
You can choose the most suitable option from the dropdown according to your preferences.
This describes the JWA Algorithm utilized for key management in encrypting the authorization response when the response mode is JWT.
Enabling this option is necessary if you want the authorization response to be encrypted.
If left blank, the authorization response is only signed but not encrypted.
You can adjust this setting and select the most suitable option from the dropdown menu according to your needs.
This pertains to the JWA Algorithm utilized for encrypting the content of the authorization response when the response mode is JWT.
Enabling this option is necessary if you desire an encrypted authorization response.
If left blank, the authorization response is signed but not encrypted.
You can customize this setting and choose the preferred option according to your requirements.
This section enables you to adjust settings for backwards compatibility with older versions of OpenID Connect / OAuth2 adapters.
This can be beneficial if the client is utilizing older editions of Keycloak/ RH-SSO adapter.
This toggle button, when activated (turned ON), excludes the 'session_state' parameter from the OpenID Connect Authentication Response.
This feature is beneficial for clients utilizing older OIDC/OAuth2 adapters that do not support the 'session_state' parameter.
If deactivated (turned OFF), the 'session_state' parameter will be included in the Authentication Response.
You can toggle it ON or OFF according to your needs.
This toggle button, when activated (turned ON), generates and adds a refresh_token to the token response.
If deactivated (turned OFF), no refresh_token will be generated.
You can toggle it ON or OFF according to your needs.
When this toggle button is activated (turned ON), a refresh_token will be generated and included in the token response specifically when the client_credentials grant is utilized.
However, according to OAuth2.0 RFC6749 Section 4.4.3, a refresh_token should not be generated when using the client_credentials grant.
If this toggle is deactivated (turned OFF), no refresh_token will be generated, and the user session associated with it will be removed.
You can toggle it ON or OFF as needed.
This toggle button, when enabled (turned ON), sets token responses with the type ‘bearer’ in lowercase. Conversely, if deactivated (turned OFF), the type will not be set in lowercase.
By default, the server sets the type as 'Bearer' according to RFC6750.
You can toggle it ON or OFF according to your needs.
This section enables you to adjust Advanced Settings for this client.
This refers to the maximum lifespan of an Access Token before it gets expired.
It is mostly recommended to keep this shorter than the SSO Timeout duration.
You can adjust the values and select the duration unit from the dropdown menu as required.
This refers to the duration for which a Client Session can remain idle before expiration.
Tokens are invalidated upon session expiry.
If not set, it defaults to the standard SSO Session Idle value.
You can adjust the values and select the duration unit from the dropdown menu as needed.
This refers to the maximum duration for which a Client Session remains active before expiration.
Tokens are invalidated once the session expires.
If not set, it defaults to the Standard SSO Session Max value.
You can adjust the values and select the duration unit from the dropdown menu as required.
This setting defines the duration for which a Client Offline session can remain idle before expiring. Offline tokens get invalidated once the client offline session expires.
You can adjust this value and select the duration unit from the dropdown menu to suit your needs.
If not set, it defaults to the Offline Session Idle value.
This setting determines the maximum duration for which a Client Offline Session remains active before expiration.
Offline tokens get invalidated upon Offline Session expiry.
You can customize the value and select the desired option from the dropdown.
If left unset, it defaults to the Offline Session Max value.
This toggle button, when activated (turned ON), enables support for OAuth 2.0 Mutual TLS Certificate Bound Access Tokens. This means that Keycloak can bind an access token and a refresh token with the X.509 certificate of a token-requesting client exchanged in mutual TLS between Keycloak's Token Endpoint and this client. These tokens can then be treated as Holder-of-Key Tokens instead of bearer tokens.
If deactivated (turned OFF), the support for OAuth 2.0 Mutual TLS Certificate Bound Access Tokens is not enabled.
You can toggle it ON or OFF according to your requirements.
This field determines the code challenge method used for PKCE (Proof Key for Code Exchange).
If left unspecified, ZTrust won't apply PKCE to a client unless the client sends an authorization request with the appropriate code challenge and code exchange method.
You can customize this field by selecting the preferred option according to your needs.
The toggle button, when enabled (toggled ON), indicates that the authorization server accepts authorization request data only via the pushed authorization request method.
If toggled OFF, the authorization server does not accept authorization request data through the pushed authorization request method.
This can be turned ON or OFF as per your requirements.
Here, you can specify which Authentication Context Class Reference (ACR) value is mapped to which Level of Authentication (LoA).
The ACR values can vary, but the LoA must be numeric.
This mapping is set up at the client level.
You can adjust this setting by adding an ACR (Authentication Context Class Reference) and LOA (Level of Assurance) pair by clicking on the '+' button, or you can remove them using the '-' button, according to your needs.
This feature pertains to the default values utilized as voluntary ACR requested by the 'claims' or 'acr_values' parameters in the OIDC request.
It serves as an editable field, providing flexibility for adjustments.
You can modify this setting by adding an ACR (Authentication Context Class Reference) value using the '+' symbol.
Conversely, to remove an existing ACR value, simply click on the '-' symbol.
This functionality ensures adaptability and customization in aligning with specific authentication context requirements within the OIDC framework.
This area permits you to customize realm authentication flow bindings.
This field is customizable, allowing you to choose the preferred flow for browser authentication (login process) from the dropdown menu.
This field is adjustable, enabling you to select the desired flow to be used for Direct Grant Authentication from the available options in the dropdown menu.
If you're satisfied with the changes and want to implement them, click on Save.
If you've made changes that you don't wish to apply, click on Reset.
Under this tab, you can configure whether to utilize a URL for downloading the client public keys or to utilize client public keys provided in JWKS (JSON Web Key Set).
This toggle button, when activated (toggled ON), enables the downloading of client public keys from the provided JWKS URL. This provides greater flexibility since new keys will always be re-downloaded whenever the client generates a new keypair.
If deactivated (turned OFF), the public key (or certificate) from the ZTrust DB is utilized. Consequently, when the client keypair changes, a new key (or certificate) needs to be imported into the ZTrust DB as well.
This switch is mutually exclusive with the Use JWKS setting.
You can customize this setting by toggling it ON or OFF according to your requirements.
When activated (toggled ON), it also enables the following field: JWKS URL.
This indicates the URL where client keys are stored in JWK (JSON Web Key) format.
Once the Use JWKS URL option is turned ON, this field becomes enabled.
You can keep it ON or OFF according to your requirements.
This toggle button, when activated (toggled ON), allows for the configuration of client public keys in JWKS (JSON Web Key Set).
This option is mutually exclusive with the Use JWKS URL key.
When deactivated (toggled OFF), the client keys will not be configurable in JWKS.
You can adjust this setting by toggling it ON or OFF as needed.
Once enabled (toggled ON), it will activate another field - Use JWKS.
This incorporates the client keys in JWK (JSON Web Key) Format.
You can see the JWK specification for more details.
Once the Use JWKS option is activated, this field becomes enabled.
It can be adjusted according to your requirements.
Upon selecting Generate new keys and certificate, you'll be directed to the following screen.
Here, you can input the necessary details to create new keys or a certificate.
This pertains to the Java Keystore or PKCS12 archive format.
You can modify it according to your requirements.
This field specifies the archive alias for your private key and certificate.
It can be changed as per your requirements.
This is the password used to access the private key in the archive.
It can be modified according to your requirements.
This password is used to access the archive itself.
You can set it up according to your requirements.
Once you have entered the details, if you wish to apply those changes, click on Generate and Download.
If you prefer not to apply those changes, click on Reset.
Upon clicking Import Certificate, you'll be taken to the following screen where you can input the required details to import the certificate.
This pertains to the Java Keystore or PKCS12 archive format.
You can customize this field according to your requirements.
It refers to the archive alias for your certificate.
You can modify this as per your requirements.
This password is used to access the archive itself.
You can modify it according to your requirements.
This setting enables you to choose a saved file for importing client certificates according to your needs. Simply click on Select file to choose the desired file from your device.
Then, click on Import to finalize the process.
If you've made some changes but decide not to apply them, simply click on Reset.
To view all the roles associated with a specific realm, click on View All Roles.
To create a new role or add a specific role, click on Add Role.
This refers to the name you choose or set up for a specific role.
This pertains to the description you can provide for a specific role, which helps in accurately identifying the role.
To finalize the creation of the role and apply any changes you've made, click on Save.
If you wish to discard the changes, click on Reset.
This section enables you to define a standardized set of protocol mappers and roles that can be shared among multiple clients.
This section enables you to configure client scopes that are associated with this specific client.
This refers to client scopes that are consistently applied when tokens are issued for this particular client. Protocol mappers and role scope mappings are always enforced, irrespective of the values used in the scope parameters of the OIDC authorization request.
These are the client scopes that have not been assigned as default scopes or optional scopes yet
If you wish to designate any available client scope as an Assigned Default Client Scope, simply select the desired scope from the Available Client Scopes list and click on Add Selected.
This section contains the client scopes that will be used as default scopes when generating tokens for this specific client.
To remove a specific client scope from the Assigned Default Client Scopes list, select the scope and click on Remove Selected.
This will remove the selected scope from the list and add it back to the Available Client Scopes list.
This refers to the client scopes that are applied when issuing tokens for this client, but only if they are requested by the scope parameter in the OIDC Authorization Request.
This section contains the client scopes that have not been assigned as default scopes or optional scopes yet.
This comprises client scopes that can be utilized as optional scopes when generating tokens for this client.
To remove a specific Client Scope from the Assigned Optional Client Scopes, select the corresponding scope and click on Remove Selected.
This will return the removed Client Scope to the Available Client Scopes list.
To add a particular client scope from the Available Client Scopes to the Assigned Optional Client Scopes, select the desired scope and click on Add Selected.
This section provides an overview of all protocol mappers and role scope mappings that will be utilized in the tokens issued to this client.
Additionally, it allows you to generate example access tokens based on the provided scope parameter.
The scope parameter is a string containing scope values separated by spaces.
You can copy and paste this value into the initial OpenID Connect Authentication Request sent from this client adapter.
Default client scopes and any optional client scopes selected will be utilized when generating a token issued for this client.
This feature enables you to choose optional client scopes that can be utilized when generating tokens issued for this specific client.
This comprises optional client scopes that may be used occasionally when issuing access tokens for this client.
This pertains to the Client Scopes that will be utilized when issuing access tokens for this specific client. You can determine above which value of the OAuth Scope Parameter should be used to apply these optional client scopes when the initial OpenID Connect Authentication request is sent from your client adapter.
To include any available optional client scope into the selected optional client scopes, simply choose the specific scope and click on Add Selected.
The newly added scope will also be included under the Effective Client Scopes.
Conversely, if you wish to remove any selected optional client scopes, select the particular scope and click on Remove Selected.
The selected scope will be removed and added back to the Available Optional Client Scopes list.
This comprises the list of all default client scopes and selected optional scopes.
All protocol mappers and role scope mappings associated with these client scopes will be utilized when generating access tokens issued for your client.
This setting allows you to optionally select the user for whom the example access token will be generated.
If no user is selected, an example access token will not be generated during evaluation.
You can search for the specific user within the realm using the provided search bar.
Clicking on Evaluate allows you to view all the protocol mappers and role scope mappings that will be utilized when issuing an access token for this client.
Additionally, it will optionally generate an example access token if a user was selected.
Protocol Mappers facilitate transformations on tokens and documents.
They are capable of tasks such as mapping user data into protocol claims or transforming any requests exchanged between the client and authentication server.
You can utilize the available Search box to search for any mapper.
To create a new Protocol Mapper, simply click on Create.
Upon clicking on Create, you will be redirected to the screen below.
This is non-editable and defaults to openid-connect.
This denotes the name of the mapper, which you can customize according to your needs.
This indicates the type of mapper that you can create.
You can review the table below to observe the various types of mappers and their respective purposes.
Claims parameter Token
The claims specified by the claims parameter are included in the tokens.
User Realm Role
Associate the user realm role with a token claim.
User Session Note
Connect a custom user session note to a token claim.
Claims parameter with value ID Token
User Address
Associate user address attributes (street, locality, region, postal_code, and country) with the OpenID Connect ‘address’ claim.
Role Name Mapper
Assign a role to a new name or position in the token.
User Client Role
Associate a user client role with a token claim.
User Property
Map a built-in user property (email, firstName, lastName) to a token claim.
Authentication Context Class Reference (ACR)
Hardcoded Role
Hardcode a role into the access token.
Hardcoded claim
Hardcode a claim into the token
Pairwise subject identifier
User’s full name
Associates the user's first and last name with the OpenID Connect 'name' claim.
Allowed Web Origins
Includes all permitted web origins in the 'allowed-origins' claim within the token.
Audience
Append the specified audience to the 'audience' (aud) field of the token.
User Attribute
Connect a custom user attribute with a token claim.
Group Membership
Map user group membership.
Audience Resolve
Include all client_ids of 'allowed' clients in the audience field of the token. An 'allowed' client refers to a client for which the user has at least one client role.
This toggle button controls whether the claim can be added to the ID Token.
When activated (toggled ON), the claim can be included in the ID Token.
Conversely, when deactivated (toggled OFF), the claim is not added to the ID Token.
You can adjust this setting as needed by toggling it ON or OFF.
This toggle button determines whether the claim should be added to the userinfo.
When activated (toggled ON), the claim will be included in the userinfo.
If deactivated (toggled OFF), the claim will not be added to the userinfo.
You can toggle this setting ON or OFF according to your requirements.
To apply the changes you've made, click on Save.
If you prefer not to incorporate the changes, click on Reset to discard them.
You can also add built-in mappers by clicking on Add Builtin to select the necessary mappers.
Upon clicking on Add Builtin, you will be directed to the screen below.
This displays the names of the existing builtin mappers.
This section categorizes the mentioned mappers.
This specifies the type of the builtin mappers.
When you want to select any specific mapper from the builtin mapper list, click on the checkbox under Add for that specific mapper.
The corresponding mapper will be selected.
At the bottom, there is an option to Add Selected, click on Add Selected to add the particular builtin mappers.
Once added, the particular mapper will be visible under the Mappers tab, as shown below.
This displays the names of the existing builtin mappers.
It specifies the category of the mappers mentioned.
This specifies the type of the builtin mappers.
Mapper implementations are prioritized based on their order in the list of mappers.
Priority order is not the configuration property of the mapper. It is the property of the concrete implementation of the mapper.
This order dictates the sequence in which changes to the token or assertion are applied, with the lowest priority mappers being processed first.
This ensures that implementations dependent on others are executed in the required order.
It contains the available actions that can be taken on the built-in mappers, such as editing or deleting the mapper.
To edit any setting for a specific built-in mapper, click on Edit.
If you wish to delete that particular built-in mapper, click on Delete.
Upon clicking on Delete, you will receive a prompt asking for your confirmation.
Click on Delete if you want to remove the mapper; otherwise, click on Cancel.
Upon clicking Edit, you will be directed to the screen below.
This is non-editable and defaults to openid-connect.
It is automatically generated upon the creation of a mapper, and it is unique to each mapper.
This denotes the name of the mapper.
This field is not editable here.
You will have the option to customize the name while creating a mapper.
This indicates the type of that specific mapper.
This toggle button controls whether the claim can be added to the ID Token.
When activated (toggled ON), the claim can be included in the ID Token.
Conversely, when deactivated (toggled OFF), the claim is not added to the ID Token.
You can adjust this setting as needed by toggling it ON or OFF.
This toggle button controls whether the claim should be included in the access token.
When activated (toggled ON), the claim will be included in the access token.
When deactivated (toggled OFF), the claim will not be included in the access token.
You can edit this field and toggle it ON or OFF according to your requirements.
This toggle button determines whether the claim should be added to the userinfo.
When activated (toggled ON), the claim will be included in the userinfo.
If deactivated (toggled OFF), the claim will not be added to the userinfo.
You can toggle this setting ON or OFF according to your requirements.
The fields mentioned above vary depending on the type of Mapper you wish to edit.
If you want to keep the changes, click Save.
If you've made changes and decide not to keep them, click Reset to discard them
This configuration enables you to limit the user role mappings included in the access token requested by the client.
This is a toggle button, when activated (turned ON), it disables all restrictions.
When deactivated (turned OFF), certain restrictions on allowed roles are imposed.
When turned OFF, you will get the following screen.
It lists all the Available Realm Roles that can be assigned to a scope. It includes roles that are effectively designated but not explicitly assigned.
It consists of the Realm Roles that have already been assigned to the scope.
It includes all the assigned roles at the Realm level that could be derived from a mapped composite role.
If you want to move any of the Available Roles to Assigned Roles, select the Role and click on Add Selected.
If you want to delete any of the Assigned Roles, select the Role and then click on Remove Selected.
Client roles are namespaces designated for clients, with each client having its own namespace.
These roles are managed within the Roles tab specific to each client.
You can assign the role to a particular client by selecting the preferred option from the dropdown menu.
In case of a system breach, you have the ability to invalidate all user sessions and access tokens.
It serves as a method to revoke all currently active access tokens.
The Not Before feature allows you to revoke any tokens issued before a specified date and time.
If you want to set the policy with the current time and date, click on Set to now.
To remove the set time and date, click on Clear to delete it.
If you want to push this revocation policy to any registered OIDC Client using the ZTrust Client Adapter, click on Push.
This section presents the active sessions associated with this specific client.
It provides visibility into which users are currently active and their respective login times.
It shows the overall count of active user sessions for this specific client.
This area presents the offline sessions associated with this specific client.
It provides visibility into which users have retrieved offline tokens and when they retrieved them.
If you wish to revoke all tokens for the client, navigate to the Revocation tab and select Set to Now.
It displays the overall count of offline tokens associated with this specific client.
This section serves as a helpful tool for generating different client adapter configuration formats, which you can either download or copy and paste to configure your clients.
Format Option
Choose the format option according to your needs.
After clicking on Edit, you will be redirected to the below screen
You can configure the settings as explained above.
This setting manages .
Claims specified with a value by the claims parameter are included in an .
Assign the achieved to the ‘acr’ claim of the token.
Generates a pairwise subject identifier using a .
