Cluster

Whether or not the Application Repository cache is enabled or disabled.

The expiration time in seconds of the cached records.

The max size of the cache.

Whether or not the refresh of the records according the change log service is enabled or disabled including event messaging.

The refresh time in seconds to refresh cached records according the change log service.

Whether or not group membership is determined from the groups stored in application-repository. These groups can be managed trough the SCIM 2.0 API.

Whether or not the 'memberOf' attribute is used to determine group membership for groups application repository. If you are using DirX directory, you must set the initial index for the member attribute in DirX directory (Schema -> Database) and configure Prescriptive ACI to allow reading the dirxMemberOf attribute (Configuration -> Root -> app repository Administrative point -> Access Control Subentries.). The membership might also contain nested and dynamic groups. For DirX directory the 'dirxMemberOf' attribute is used, for AD 'memberOf' is used. In DirX directory this will result in faster search for recursive group membership.

Whether or not roles are determined from the application repository.

Whether or not nested groups are resolved for the groups resolved from application repository. If enabled it will be possible to add groups as members trough SCIM and membership in nested groups will be resolved for the users. Note that when DirX directory is used as application repository, the groups must have at least one member (according to DirX directory documentation), so it can be resolved as parent group. If you want to force not resolving nested groups, you should also disable usage of the 'memberOf' attribute.

Whether or not roles for the user are resolved from the groups saved in the application repository. If enabled it will be possible to add roles to groups trough SCIM and roles will be resolved for the users from the groups. Determining of roles from application repository must also be enabled.

The format of the group name that will be used in request injections for groups resolved for the Application Repository. If empty, the FQN of the group will be returned. The format can contain placeholders for the group name (CN) (#1) and a domain (#2). The placeholders are replaced with the actual values when the group is added to a request injection.

The domain that will be used in request injections for groups resolved for the Application Repository. The 'Group name format (application-repository groups)' must not be empty in order for the domain name to be used.

Whether modification operations are allowed during import from startup folder during DirX Access Server startup. If enabled, entries can be modified during import. If not enabled, already existing entries are moved to a partial file that can be reviewed manually and imported in next DirX Access Server startup.

The audit level for the authentication service.

The audit level for the actual decision making of the authorization service. Enabling auditing for the authorization service typically leads to the production of an extensive amount of audit messages. Make sure you carefully consider the value of this setting.

The identifier for the callout handler that is responsible for auditing events (default: Log4JAuditCalloutHandler).

The emergency strategy for the auditing source. Auditing sinks are required to be able to handle the number of audit events produced. The emergency strategy addresses the case when the auditing sink cannot satisfy this requirement. The currently recognized values are DROP, THROTTLE and NONE. With the drop strategy, the loss of audit events is permitted but performance is not degraded. With the throttle strategy, performance degradation is permitted but audit events cannot be lost. With the none strategy will drop events without emitting any warning to the log file.

The audit level for the federation service.

Whether or not lower-level authorization decisions are audited. This setting is applicable to authorization decisions made by secondary PDPs (typically, Role-Enablement Authorities). Unchecking this option may decrease the volume of audit data.

The maximum queue size for the auditing service. A value of 0 specifies an unlimited audit queue size.

The identifiers for request injection templates to be used to customize audit event contents. Use this field to assign request injection template configuration objects to the DirX Audit service that instruct the service on how to provide customized information in audit event objects. This extension to the DirX Access audit service also requires auditing sinks that implement a consumer that uses the AuditEvent Java class Map<String, String[]> getCustomProperties().

The audit level for the server lifecycle.

The audit level for the SSO service.

The audit level for the Application Repository service.

The number of threads assigned to servicing the auditing queue. Increasing this value can increase auditing service performance but will use more system resources.

The audit level for the user service.

The identifier of the authentication authority returned in the SSO_SERVICE -> AUTHENTICATION_INFO -> AUTHENTICATION_AUTHORITY request injection value and as an issuer of the FEDERATION_SERVICE -> ISSUED_SAML_ASSERTION SAML assertion.

The identifier of the callout handler for the attribute finder plug-in.

The identifier of the callout handler for the authentication token finder plug-in.

The identifier of the callout handler for the name mapping plug-in.

Whether or not the domain names are persisted in the Application Repository, enabling an inter-session user-specific data merging. For more information, see the section 'Name Resolution' in the appendix 'Advanced Topics'.

Whether or not to enable anonymous subject to be the result of the authentication process.

Whether or not it is required to have a user consent with collecting user data when storing RBA related data.

A non-negative value that determines the number of backups performed for caches that do not completely replicate their state on all of the services servers in the cluster (partitioned caches).

Whether or not the shared cache communication is protected by SSL/TLS.

The identifier of the crypto container to be used to establish SSL context (for 'KeyManagerFactory') in case the shared cache communication is protected by SSL/TLS.

The identifier of the crypto container to be used to establish SSL context (for 'TrustManagerFactory') in case the shared cache communication is protected by SSL/TLS. The keystore is tried to be used instead in case truststore is not set.

Whether or not the static cluster resolution mechanism shall be used.

Map of cache servers consistent identifiers (address : port) as keys and the data centers given server resides as values.

If true, the algorithm guarantees to assign at least one backup copy (if configured) to a cache server residing in different data center than the primary created record (the primary record is stored in the cache server that is primary to the DXA server creating the record).

The host name of the cluster. Please note that the maximum supported hostname length is 128 ASCII characters. The value must be without scheme and port.

The decision whether or not the Crypto cache is enabled or disabled.

The expiration time in seconds of the cached records.

The max size of the cache.

The identifier of the callout handler handling CRL finder events.

Whether or not the persistent SAML NameID is supported (applicable to SAML IdPs).

The maximum number of SAML assertions stored for session (-1 means no limit).

The operating mode of the SSO cache. Possible values are:

The identifiers of the callout handlers handling SSO events.

Whether or not SSO session correlation is performed.

The maximum number of authenticated subject representations the SSO service can maintain.

The length (in bytes) of the (random) identifiers to SSO session objects.

The interval (in seconds) at which subject refresh is performed. A value greater than zero defines the number of seconds after a refresh at which the subject is refreshed again. A value of 0 means that the subject is refreshed regardless of the time elapsed since the last refresh. A negative value means that subject refresh is not performed.

The interval (in seconds) between two consecutive SSO requests during which the subject’s internal state (for example, last access time) is not updated. A value greater than zero defines the number of seconds after an update at which the subject is updated again. A value of 0 means that the subject is updated regardless of the time elapsed since the last update. A negative value means that subject update is not performed. An appropriate value (for example, 1 second) improves cache performance (by decreasing the number of synchronization messages).

The interval (in seconds) at which to check the timeout or idle timeout of SSO session objects.

If true, the JWT token will be used for representation of the session identifier. Otherwise, the random string representation will be used.

References to cryptographic material containers.

The maximum number of entries returned when performing user searches. Note that you cannot exceed a possible server-side size limit.

Whether or not the user cache is enabled or disabled.

The expiration time in seconds of the cached records.

The max size of the cache.

Whether or not the LDAP query optimization is enabled or disabled. Only configured LDAP attributes are requested from the user repository. These LDAP attributes are derived from the current DirX Access configuration.