Plugin Referenz - Airlock IAM 8.6.0

If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.

A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.

Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.

Custom attributes are not returned for 'retrieve' endpoints.

Defines the accepted SSO ticket repository from which expired tickets are to be removed.

Note that this repository may be different from the one configured in the service container which stores accepted SSO tickets used to access it and rejects previously accepted ones.

During clean-up, accepted SSO tickets are deleted in batches of this size.

This ensures that any row locks on the database are very short-lived, not affecting parallel ticket insertions. This value should not be set too high to prevent very long running transactions. Accepted SSO ticket clean-up will repeat deleting this number of tickets until all expired tickets have been cleaned up. Therefore, this task can take some time when a lot of accepted SSO tickets are present.

This size should be chosen so that every batch does not take longer than 5 seconds. The average runtime of the batches can be found in the task's logs.

In many cases, the submit button value must be sent to an application to make it think that the button has been pressed.

Only allow connections to servers whose certificate is trusted. See documentation of property "Trust Store Path" for more information about what certificates are trusted.

Security warning: Trusting all certificates allows connections to adversarial hosts. Only disable this property for testing and integration setups.

Enables hostname verification, i.e. the actual hostname must be the same as in the server certificate.

Security warning: Not verifying the hostname may allow connections to adversarial hosts, e.g. if they employ DNS spoofing. Only disable this property for testing and integration setups.

If this property is not defined the following certificate issuers are trusted:

• The list of issuers known to the Java VM if the system property "javax.net.ssl.trustStore" is not defined.
• The list of issuers in a keystore referenced by system property "javax.net.ssl.trustStore" if defined in instance.properties using iam.java.opts

If this property is defined then the following certificate issuers are trusted:

• The list of issuers in the referenced truststore file and no others.

This property is only relevant if the property "Allow Only Trusted Certs" is enabled.

Depending on the keystore type, leaving this property empty (or undefined) has a different effect:

• In keystores like JKS, the keystore can be opened and used but the integrity of the keystore is not checked.
• In keystores like PKCS12, the keystore cannot be opened an an error occurs.

When configured, all requests sent contain a header with the correlation ID with the configured name. If no value or an empty value is specified, the correlation ID header is not sent.

If the correlation ID is not defined, the correlation ID header is not included in sent requests.

If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.

If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.

A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.

A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.

Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.

Custom attributes are not returned for 'retrieve' endpoints.

If configured, an additional button is displayed on the account link management to exit the page. On click, this button redirects the user to the configured target.

To redirect to a target application, redirect to the corresponding "Authentication Flow". If the flow can be skipped due to the obtained tags, the user is directly forwarded to the target application.

If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.

If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.

A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.

A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.

Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.

Custom attributes are not returned for 'retrieve' endpoints.

Precondition that must be fulfilled for a user to access the account link and provider list.

• Access Condition: This condition determines whether a user is allowed to access a service at all. If this condition is not fulfilled, there is nothing that can be done (at least not immediately). Typical examples include having a certain authentication token, or a certain static role. This condition is always checked before the Authorization Condition and if it fails, the REST response has status 403 with error code PRECONDITION_NOT_FULFILLED.
• Authorization Condition: This condition determines whether the user is currently authorized to access a service. It is expected that completing another authentication flow (step-up) would enable the user to then fulfill the condition. The typical authorization condition checks whether the user has obtained a certain tag (or combination of tags). If the condition fails, the REST response has status 403 with error code NOT_AUTHORIZED.

• Access Condition: This condition determines whether a user is allowed to access a service at all. If this condition is not fulfilled, there is nothing that can be done (at least not immediately). Typical examples include having a certain authentication token, or a certain static role. This condition is always checked before the Authorization Condition and if it fails, the REST response has status 403 with error code PRECONDITION_NOT_FULFILLED.
• Authorization Condition: This condition determines whether the user is currently authorized to access a service. It is expected that completing another authentication flow (step-up) would enable the user to then fulfill the condition. The typical authorization condition checks whether the user has obtained a certain tag (or combination of tags). If the condition fails, the REST response has status 403 with error code NOT_AUTHORIZED.

Non-backward compatibility: Before hierarchical plugins were released, the RadiusServer informations were all configured directly in this plugin with a comma separated list. This must be converted by hand.

If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.

If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.

A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.

A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.

Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.

Custom attributes are not returned for 'retrieve' endpoints.

If enabled, the Active Connector plugin does not write any data to the AD except for new passwords (changing and setting passwords can be disabled in the global password settings).
This allows using a service account user with only few privileges.

If enabled, the following data is not written to the AD (and therefore some features may not work as expected):

• Context data (e.g. changes to user's postal address)
• Credential data (e.g. change of mobile phone number)
• User unlocking (after password change or from the Adminapp)
• Enforcing password change (after setting a new password in the Adminapp)

Note that individual context attributes can be made read-only using the configuration property "Read-Only Attributes".

The LDAP attribute with credential data (e.g. mobile phone number for mTAN/SMS authentication or email address for certificate validation).
If the same attribute is listed in the property "Binary Attributes", it will be treated as binary data, otherwise it is assumed to be UTF-8 string data.

This property is only required when an additional credential should be checked besides the password.

The separate property "User Search Scope" controls whether users are only searched in the nodes defined by this property or in its subtrees as well.

• ONE_LEVEL: Search users only in the specified "User Search Bases" - the subtree is ignored.
• SUBTREE: Search users recursively in the specified "User Search Bases" - considers the complete subtree.
• SUBORDINATE_SUBTREE: Search users recursively in the specified "User Search Bases" - considers the complete subtree from one level below the specified "User Search Bases" and ignores users directly in it.
• BASE: Only the exact entries in the specified "User Search Bases" are considered.

LDAP search filter expression applied when searching for users.
Note that this filter is automatically combined (logical AND) with a username filter based on the "Username Attribute".
The format and interpretation of filter follow RFC 2254.

Example 1 - Consider only entries with object class user: (objectCategory=user)
Example 2 - Consider only entries with object class person: (objectClass=person)
Example 3 - Consider only users in a specific group (no nested groups): (&(objectCategory=Person)(memberOf=cn=snakeOilDepartment,ou=groups,dc=company,dc=com))
Example 4 - Same as example 1 but considering nested groups: (&(objectCategory=Person)(memberOf:1.2.840.113556.1.4.1941:=cn=snakeOilDepartment,ou=groups,dc=company,dc=com))

Regular expression pattern containing a group (a region embraced by parentheses) that can be used in conjunction with property "Username Conversion Replacement" in order to transform the username before it is used for searching the user in the directory. If the username does not match the pattern at all, no transformation is performed.

Example: The pattern "(.*)" and the replacement pattern "user.$1" will transform the username "jdoe" to "user.jdoe" before it is used in the directory.

Example: The pattern "user\.(.*)" and the replacement pattern "$1" will transform the username "user.jdoe" to "jdoe" before it is used in the directory.

Groups/roles are not searched if this property is not configured.

The separate property "Group Search Scope" controls whether groups are only searched in the nodes defined by this property or in its subtrees as well.

• ONE_LEVEL: Search groups only in the specified "Group Search Bases" - the subtree is ignored.
• SUBTREE: Search groups recursively in the specified "Group Search Bases" - considers the complete subtree.
• SUBORDINATE_SUBTREE: Search groups recursively in the specified "Group Search Bases" - considers the complete subtree from one level below the specified "Group Search Bases" and ignores groups directly in it.
• BASE: Only the exact entries in the specified "Group Search Bases" are considered.

Note that this filter is automatically combined (logical AND) with a username filter based on the "Username Attribute".
The format and interpretation of filter follow RFC 2254.

Notice that in any case, only groups in the "Group Search Bases" will be found.

Note that nested roles can NOT be resolved via the memberOf attribute. This can only be done using the groups search. The role lookup through the memberOf attribute is readonly, as is the lookup through the groups search.

If set to a value greater than zero and the Active Directory supports the SimplePaging control, "paging" is enabled for LDAP searches: This property defines the number of entries to fetch at once when searching in a directory.

This setting may be useful if the Active Directory limits the number of entries in a search result.
If the property is set to zero (the default) or if the server does not announce to support the SimplePaging control, paging is disabled

Lock users when they have more than the configured number of successive incorrect password checks on the AD. (E.g.: the value "2" means that 2 incorrect passwords are still OK).

If the number is smaller than the corresponding setting in AD, this allows "soft-locking" the account if accessed via Airlock IAM without actually locking the account on the AD. This feature may be used to prevent AD accounts from being locked by unsuccessful remote logins.

Note: if "Stealth Mode" is used (see "Main Authenticator" plugin), it is strongly recommended to enable this feature.

If enabled the server side password policy is checked when a user changes or resets the password (not when an administrator sets one). This is for example useful to enforce advanced server-side policies like password histories.

Note that the AD might impose further password constraints (e.g. minimal length), that cannot be weakened or disabled with these settings.

To prevent attributes from being changed by Airlock IAM/Login, add them also to the list of "Read-only Attributes".

Notice: The attributes "objectGUID" and "ImmutableID" are always considered read-only.

Those attributes are Base64 encoded for use in Airlock IAM/Login.

If the attribute name from "Credential Data Attribute" is also listed here, the credential data will be treated as binary.

Note: The user count is relevant for the product license. This filter should therefore describe the set of users who are able to authenticate through Airlock IAM.

Valid values are SUB and ONE.

The format and interpretation of filter follows RFC 2254.

If a password is changed, the 'latest password change timestamp' is set and, if this property is defined, the 'next enforced password change timestamp' is updated.

If this property is not defined, the 'next enforced password change timestamp' is not updated.

The suffix of the attribute name gives a hint on the data type that this attribute expects in the context data field:

• NV a named value meaning one of a known set of well string keys as defined in the latest FreeRadius dictionary.
• STRING an UTF8 encoded string.
• INT a number that can be represented by 4 bytes.
• BYTES either a byte array or a base64 encoded string.
• IPV4 either an IPv4 address object, a host name or a raw 4 bytes internet address.
• IPV6 either an IPv6 address object, a host name or a raw 16 bytes internet address.
• DATE either a Date object or a number representing seconds since 1.1.1970.

The values that will be added to the scope.

Scope tokens must consist of the following characters: %x21 / %x23-5B / %x5D-7E (see RFC6749)