Configuring the ActivID AS Properties

The principal ActivID AS properties are contained in the system configuration files. The following sections provide guidelines for the settings contained the files.

Warning! ONLY modify the files if you are sure that you are making the correct changes. Modifying the properties files incorrectly can render the system unusable.

It is recommended that you contact HID Global Technical Support before modifying these properties.

Note: Settings in the properties files can affect some aspects of system performance.

Properties Files

The properties of the ActivID AS system (applications and features) are organized in the following .properties files that are called by ActivID AS.

All entries are commented with the default values.

For details about each property, refer to the property’s comments.

Note: For reference, <ACTIVID_HOME> represents the ActivID AS software installation directory (by default, /usr/local/activid).

Modify a Property

  1. To modify the properties, it is recommended that you first Generate a Customization Package.

  2. Modify the relevant properties in the generated configuration files of the customization package (and not the original properties files on the file system).

    3. To change the default behavior, uncomment the property and set your required value.

  3. Apply a Customization Package.

  4. Restart the server.

Important: You must restart the system in order to apply the modifications for any of the files.

Configure the Authentication Services Settings

You can configure the hostname and port for the ActivID Authentication Services and ActivID Authentication Web Services.

See also:

Update the HTTPS Ports or Proxy Hostname/Ports

Configure Forward Proxy Support

Configure the Safeguarded Critical Entities Settings

Configure the Cache Settings

To enhance performance and the retrieval of business configuration data from the database, ActivID AS can be configured to cache this data for a period of time.

This mechanism allows reading objects from the database only when the objects have been updated since the last access. In this case, the corresponding cache value is also updated.

Therefore, the cache values are always synchronized with database objects in a single server node deployment.

For cache synchronization across several nodes, ActivID AS stores caches timestamps in the database, allowing all nodes to check if they need to refresh their local cache values when an object has been created/updated or deleted in the database by another node.

For example, if an adapter configuration is created/updated/deleted on one server node, this node will update the corresponding cache timestamp in the database, allowing other nodes to refresh their local caches (by comparing the local cache timestamp with the timestamp on database).

To avoid reading the caches timestamps from the database at every request, server nodes will, by default, read this value every 10 seconds (defined by the CACHE_TIMESTAMPS_REFRESH_INTERVAL property). Therefore, this value represents the maximum latency period of object change visibility across all server nodes.

Cached objects are discarded from cache if not accessed during a period defined by the following Cache timeout values. This allows reducing the memory footprint for objects that are rarely used. It also means reduced memory footprint for unused security domains.

The timeout values (normally in milliseconds) for these caches indicate when this data is discarded. Any entry in the activid_server.properties file with a property name ending with _CACHE_TIMEOUT can be altered to reflect how long the data is cached for.

The following caches values are discarded if not used for the above duration:

The following cache value is discarded after the period defined by the timeout (even if accessed). This allows forcing the refresh of the cache value.

Configure the Search Limits

Searches performed in the ActivID AS portals can place a large load on the application. The number of records displayed should be limited to a reasonable size. The ActivID Authentication Server contains a method to limit the number of records that can be returned from the database. Returning larger result sets does place a strain on the server in terms of memory (need to keep the result set) and in terms of HSM load since ActivID AS verifies each records data signature.

If search performance is slow, very slowly, or there are 'out of memory' errors on ActivID Authentication Server application server instance nodes, you might need to adjust the search limits.

It is recommended that search limits (with a property name starting with SEARCH_) should be kept to a reasonable size (such as the default values).

For example, to configure User or Device search parameters, select the customizable activid_server.properties core properties file, then update the following:

Important: As these settings might impact the search result display performance in the ActivID Management Console, you can add a parameter in the mgtcons.properties file to restrict search limit to a value lower than the value set in activid_server.properties file.

The user or device search performed in the ActivID Management Console will take into account the limit set in mgtcons.properties file.

To configure User or Device search parameters for the ActivID Management Console, in the mgtcons.properties file, update the following:

# Max numbers of devices displayed by the Management Console. Note: This number is ignored if it is greater than the SEARCH_LIMIT_TOKEN (activid_server.properties)
# Uncomment to enable.
#com.actividentity.iasp.ui.maxdevicesearch=100
# Max numbers of users displayed by the Management Console. Note: This number is ignored if it is greater than the SEARCH_LIMIT_USER (activid_server.properties)
# Uncomment to enable.
#com.actividentity.iasp.ui.maxusersearch=100

Configure the Truststore Settings

Configure the Audit Settings

See also Add a Custom Audit Adapter for details on deploying custom audit adapters.

Important: By default, in order to assist customers in meeting the requirements of certain data protection regulations, personal data in the audit log is tokenized/anonymized.

Disclaimer: If your organization requires audit log data to be detokenized for specific needs and usages, HID Global offers guidance in the form of APIs, sample code, and utilities, and it is recommended to adopt that approach while leaving the audit tokenization feature enabled.

Prior to disabling audit tokenization, it is recommended that you consult with your legal department to align with your organization’s policies with regard to the processing of personal data.

Audit Sequence Settings

Each ActivID AS instance is allocated a dedicated pool of audit sequences. For security reason this pool is limited in size (default limit is 100). To avoid contentions make sure that application server worker threads can always immediately acquire a free sequence.

The ActivID Authentication Server log files might indicate if the sequence pool has run out of available sequence generators. For example, "No more sequence generators: pool at max size of XX and pool empty" where XX is defined below”.

If this occurs, make sure the audit sequences matches the maximum number of worker threads allowed in the J2EE application server by setting the value of the SEQ_GEN_POOL_MAX_SIZE property.

It is recommended that the tuning of the application server (changing the threads etc.) should be done in parallel with this setting.

Also see the guidelines on tuning the system in the ActivID AS installation guide for your application server available from the ActivID Customer Portal.

Audit Security Enhancements

Audit Log Resilience

On a busy server, the audit log can grow quickly and, in some cases, can exceed the amount of space available for storing the audit data.

The ActivID AS might have sufficient data space available to continue its normal operations despite the failure of the audit log.

If the audit log has been overrun because of underestimating the space required for it, certain operations can continue working despite the fact that those calls will not be logged.

When the audit fails (for an authentication or administration operation), ActivID AS behavior depends on the configuration of the Resilience to Audit Log Failure properties (ALLOW_XXX_TO_PROCEED_WITHOUT_AUDIT_<DOMAIN>):

  • If the Resilience to Audit Log Failure is allowed:

  1. Write Audit log value to the following file:

    <ACTIVID_HOME>/ActivID_AS/servers/server_<n>/logs/activid-server-audit.log.<domain>

  1. Proceed as normal.

  • If the Resilience to Audit Log Failure is denied:

  1. Write Audit log value to the following file:

    <ACTIVID_HOME>/ActivID_AS/servers/server_<n>/logs/activid-server-audit.log.<domain>

  1. Prevent the operation.

If, during execution of the ActivID AS, the audit log begins to fail, use the following procedure to change the Resilience to Audit Log Failure (RALF) settings at runtime.

Note: You can configure this behavior separately for each security domain.

For each security domain configured on the ActivID AS instance, two properties can be added to the <ACTIVID_HOME>/ActivID_AS/applications/resources/common/activid.properties file (illustrated with DOMAIN1 as the security domain):

Note:

  • If the ALLOW_XXX properties are not defined, then the default value is DENY so both authentications and other configuration processes will fail if the audit log has failed.

  • As all operations require authentication, ALLOW_AUTHENTICATION must be set to ALLOW if you also set ALLOW_ADMINISTRATION to ALLOW.

Configure User Case Sensitivity

To configure User Case Sensitivity, set the CASE_SENSITIVE property to true.

To illustrate the case when the user case sensitivity is set to true, the following summary is used as an example:

  • The user “jdoe” is unable to authenticate if you enter “JDOE” in the login page username field, they can only authenticate if they enter “jdoe”.
  • The user “jdoe” is not returned in a user search if you enter “JDOE” in the search field, only if you enter “jdoe”.
  • You are able to create simultaneously a “JDOE” and a “jdoe” user.
Note: By default, user search and user authentication are not case-sensitive and the user case sensitivity is set to false. This means that:
  • The user “jdoe” can authenticate if you enter “JDOE” in the login page username field.
  • The user “jdoe” is returned in a user search if you enter “JDOE” in the search field.
  • You are unable to create simultaneously a “JDOE” and a “jdoe” user. A warning message appears reporting the user already exists.

Configure Generic Dictionary to User Attribute Mapping

The user attribute mapping is used in the context of the Authorization Profiles Selection Rules.

Note:  

  • This mapping is shared by all security domains.

  • Setting FORCE_SERVER_GENERIC_RULE to true enables this mapping for generic dictionary attribute used in check before authorization profile rules when the comparison attribute selected in the check before rule is a static value. When the comparison attribute selected in the check before rule is dynamic (ActivID AS attribute), the check before attribute from generic dictionary is mapped to the attribute coming with the authentication request.

This is the default configuration.

When the setting is false, the check before attribute from generic dictionary is mapped to authentication request attribute.

The following entries define the mapping of attributes that applies when FORCE_SERVER_GENERIC_RULE is true.

Note: When the “Property value” is not defined, any custom value can be set.

Configure the Default Status Category Workflow

Configure Adapter Settings

Add Adapter Definitions

In the activid_server.properties file, the following entries can be used to add new adapters to ActivID AS:

  • ADPTR.AUTHENTICATION.adptr%nb – authentication process adapters

  • ADPTR.AUTH_MANAGER.adptr%nb – authenticator management adapters

  • ADPTR.CREDENTIAL.adptr%nb – credential management adapters

  • ADPTR.OOB.adptr%nb – delivery gateways adapters

  • ADPTR.DEVICE.adptr%nb – device management adapters

  • ADPTR.DATASOURCE.adptr%nb – LDAP adapters

  • ADPTR.PROCS.adptr%nb – authentication pre or post-process adapters

  • ADPTR.USER_MANAGER.adptr%nb – user management adapters

  • ADPTR.DEVICE_IMPORT.adptr%nb – device import adapters

  • ADPTR.AUDIT.adptr%nb – adapters to handle audit event  notifications

  • ADPTR.ORGANIZATION.adptr%nb – organizations adapters

For example, to add a new custom device adapter with a Java implementation class name that is com.test.mydeviceadapter:

  1. Locate the #ADAPTER_TYPE_DEVICE: template ADPTR.DEVICE.adptr%nb entry.

  1. Add the following line using next available adapter number for the adapter template (for example, for the first device adapter, use adptr1) :

    ADPTR.DEVICE.adptr1=com.test.mydeviceadapter

For further information about developing new adapters, contact HID Global Technical Support.

Credential Adapters

Import Device and Import Adapters

Global Process Adapters Parameters

Configure the Concurrent Login Policy

The Concurrent Login Policy enables you to limit active sessions to a single session at a time for a single user account. Concurrent Login Policy is configured globally per domain.

When the concurrent login policy is enabled, only one login session is permitted per user. Within the same browser session, different service providers/channels can be accessed for the same user account using the same session.

When the same user tries to access a service provider (for example, the ActivID Management Console) from another browser session, the authentication is denied as long as the other session remains opened. The user must wait until the other session is closed or is timed-out.

If a user tries to launch a concurrent login session, the error message “Login is denied. You cannot log on as long as your previous session remains open. Log out from the previous session or wait for the session to time out and try again” is displayed.

When LOGIN_POLICY_SESSION_DUPLICATE_FAIL_<DOMAINX> is absent (the default and equivalent to false), then the ActivID Authentication Portal allows concurrent login.

Configure the Direct Authentication Failure Response Details

Configure the RFE Forward Reasons Codes

The following codes are the RFE forward reasons codes that are enabled by default. The complete list of reason codes can be found in the ActivID AS API Javadoc documentation.

To modify the settings, update the values in the following properties.

Configure the ActivID SCIM Settings

Configure the Safeguarded Critical Entities Settings

Several critical ActivID AS system entities are safeguarded against updates that could interfere with the system stability or access.

To edit these entities, you must have a higher level of privilege defined by the OVRD_SAFEGUARD (Override Safeguard) permission that is only assigned to ActivID AS administrators (in the ActivID Administration Functions permission set).

The Safeguard check is performed for the following operations:

  • Delete or update of Authentication Types

  • Delete or update of Device Types

  • Delete Roles

You can define the comma-separated list of protected entities in the SAFEGUARDED_ENTITIES_CODES.

For example:

SAFEGUARDED_ENTITIES_CODES=DT_TDSV4,AT_TDS

Configure the Certificate Validation Settings

You can define the settings to check the trust chain of client certificate on import and certificate revocation status for PKI C/R authentication.

Configure the EMV Card Import Settings

You can customize the EMV card profile settings that ActivID AS uses to import EMV cards.

The profiles are properties that are defined in the emvCardImportDefaults.properties file (in <ACTIVID_HOME>/ActivID_AS/applications/resources/srv/) and contain a minimum set of card and key data that is applied to all cards associated to that profile:

  • IIPB – Internet Proprietary Bitmap

  • masterKeyLabel – string label name of the master key from which the card keys will be derived

  • AIP – Application Interchange Profile

  • CVR – Cardholder Verification Results

  • IAF – Internet Application Flags

  • Additional definitions required by the EMV CAP specification for verification:

    • terminalCountryCode
    • terminalVerificationResult
    • transactionCurrencyCode
    • transactionDate
    • ATC – Application Transaction Counter
    • CVN – Cryptogram Version Number

  • Additional definitions required by ActivID AS for EMV CAP specification for verification:

    • authType
    • authVersion
    • CVRMask
    • extendedCVRMask
    • truncatedARQCLength
    • truncatedATCLength

For example, you could create a profile called EMVProfile1 with the following configuration:

Copy 
EMVProfile1.IIPB=8000FFFFFF00000000000000000000000000
EMVProfile1.masterKeyLabel=masterkey123
EMVProfile1.AIP=1000
EMVProfile1.CVR=03A49000
EMVProfile1.IAF=00
EMVProfile1.terminalCountryCode=0000
EMVProfile1.terminalVerificationResult=8000000000
EMVProfile1.transactionCurrencyCode=0000
EMVProfile1.transactionDate=010101
EMVProfile1.ATC=0000
EMVProfile1.CVN=0A
EMVProfile1.authType=1
EMVProfile1.authVersion=0
EMVProfile1.CVRMask=0000
EMVProfile1.extendedCVRMask=00
EMVProfile1.truncatedARQCLength=5
EMVProfile1.truncatedATCLength=3