AuthnMethodFido

FIDO authentication method configuration. The use of the FIDO authentication method requires the authenticated entity to preregister the FIDO credentials. The registration process can be managed directly via the FIDO authentication method.

Description

Description of the configuration object

Assurance level

A numeric weight to be assigned to this authentication method. You can create authorization conditions based on these assurance level weights.

Communication URLs holder

The holder for common URL configurations of an authentication method.

Prefix for URL definitions

The prefix for URL definitions. The base URL, specified as an absolute or relative path, to which users will be directed when events occur during the authentication workflow when using this authentication method. DirX Access redirects the authenticating user to the pages specified in the following fields.

Pre-login

The URL of the page to load before the login page, relative to 'Prefix for URL definitions'.

Login

The URL of the login page where users provide credentials for form-based authentication methods, relative to 'Prefix for URL definitions'.

Login success

The URL of the page to load when authentication succeeds, relative to 'Prefix for URL definitions'.

Login failed

The URL of the page to load when authentication fails, relative to 'Prefix for URL definitions'.

Error

The URL of the page to load when an error is encountered, relative to 'Prefix for URL definitions'.

Account expired

The URL of the page to load when the user’s account has expired, relative to the 'Prefix for URL definitions'.

Account locked

The URL of the page to load when the user’s account has been locked, relative to 'Prefix for URL definitions'.

Account disabled

The URL of the page to load when the user’s account has been disabled, relative to 'Prefix for URL definitions'.

Do correlate user accounts

Whether or not the authentication service correlates user accounts in the 'User Repository' upon successful validation of provided credentials. SAML assertion based authentication at SPs should consider unchecking depending on the underlying scenario.

  • For traditional initial authentication, the correlation is made based on the login name and the LDAP attribute 'Login name attribute' that can be configured in the SubjectTemplate configuration.

  • For X.509 certificate-based authentication, the correlation details can be configured on the basis of dedicated configuration fields in AuthnMethodX509 configuration.

  • For Kerberos or NTLM-based Windows authentication, the correlation is made based on the RFC 822 login name and the 'Mail attribute' that can be configured in the SubjectTemplate configuration.

  • For federated authentication based on SAML assertions, the correlation details can be configured in specific SAML assertion interpretation templates.

Do honor validity metadata

Whether or not the authentication service considers validity metadata for example, account lifetime or locking state.

Do use attribute finder

Whether or not the authentication service invokes the server-global subject attribute finder plug-in for this authentication method. This plug-in allows you to look up supplementary information about an authenticated user that is not part of the user account against which authentication was performed and is used when information about a single user is distributed across various repositories.

SAML authentication context class reference

A value to be imprinted as SAML authentication context class reference when issuing SAML assertions for subjects that have been authenticated with this method. If the value is undefined, a default mapping to SAML-defined values is used.

Do autogenerate domain identifier and format

Whether or not to generate the authentication-method-specific domain name in the format: authentication_id@authentication_method_id.

Domain identifier

The domain identifier used for the names retrieved by this authentication method during the domain name resolution.

Domain name format

The domain name format used for the names retrieved by this authentication method during domain name resolution. The format may contain placeholders: #1 (replaced by the authentication identifier), and #2 (replaced by the domain identifier).

Do hash authentication id

Whether or not the authentication identifier is hashed before it is included into the domain name.

User Correlation Policy

To what extent is the user correlation with an existing user record in user repository for this authentication method forced. This element has priority over the Do correlate user accounts element.

  • MANDATORY: The authentication method will fail if the user correlation cannot be made.

  • OPTIONAL: The server will try to correlate the user with a user record, but if the correlation fails the method will still pass if possible.

  • NONE: No user correlation will be done.

  • Allowed Values:

    • MANDATORY

    • OPTIONAL

    • NONE

Shared credentials authentication method identifier

Reference to authentication method of the same type to share the credentials and credential-specific configuration with. If null, this method works with its own configuration and set of credentials for each user. For every authentication method the domain name configuration is being resolved which is then used during unique name resolution. Specifics for some methods are:

  • AuthnMethodPassword - number of login failures, password from the user record with its respective configuration and max number of consecutive login failures from the authentication method configuration.

  • AuthnMethodOtpRfc4226 - number of login failures, shared secret and counter from the user record and number of digits, throttling value, shared secret encoding and look ahead from the authentication method configuration.

  • AuthnMethodOtpRfc6238 - number of login failures, shared secret and time drift from the user record and number of digits, throttling value, shared secret encoding, time step seconds and time drift limit from the authentication method configuration.

Just-in-time provisioning of user record to AppRepo

Indicates whether Just-in-Time (JIT) provisioning of user records to the application repository is enabled. If enabled, a user record is automatically created in the application repository after successful authentication if it does not already exist. If disabled, authentication will not trigger the creation of a new user record if one does not exist.

Supported FIDO specification

The type of specification supported by this authentication method. DirX Access supports "Web Authentication", "Windows Hello", "FIDO UAF" and "FIDO U2F" versions of FIDO-based specifications.

  • Allowed Values:

    • webAuthn

    • uaf

    • u2f

Attestation Conveyance Preference

The type of attestation conveyance preferred by the DirX Access server. The property is relevant only for the Web Authentication specification.

  • None: the relying party is not interested in authenticator attestation.

  • Direct: the relying party wants to receive the attestation statement as generated by the authenticator.

  • Indirect: the relying party allows the client to decide how to obtain a verifiable attestation statement. The client may replace the authenticator-generated statement.

  • Enterprise: the Relying Party wants to receive an attestation statement that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators.

  • Allowed Values:

    • none

    • direct

    • indirect

    • enterprise

Application identifier

The identifier of the DirX Access server used in the authentication protocol. This element has different semantics for each supported protocol version.

  • Web Authentication: The 'Application ID' must be a registrable domain suffix or must be equal to the effective domain at which the Authentication Application resides.

  • Windows Hello: The 'Application ID' can be represented by any value except an empty string. Registered Windows Hello credentials can be used only by the authentication methods with an 'Application ID' that is equivalent to the one used during the registration.

  • FIDO U2F and FIDO UAF: The 'Application ID' determines what applications can ask for the authentication at the client side. It is subsequently returned as a part of the response to be checked against the 'Allowed origins' attribute.

    • Empty: the relevant application identifier is set at the side of the FIDO authenticator.

    • HTTP URI: this URI must exactly match the URI at which this authentication method (typically Authentication Application) is used.

    • HTTPS URI: this URI must be set to the URI of the Authentication Application.

    • Android FacetID: This URI must be derived from the base64 encoding of SHA-1 hash of the APK signing certificate android:apk-key-hash:<base64 encoded sha1 hash of apk signing certificate>.

    • iOS FacetID: This URI must be the BundleID URI of the application. ios:bundle-id:<ios bundle id of application>.

Server challenge length

The number of random bytes used for the challenge generated by the server. This value should reflect the security considerations valid for given DirX Access deployment.

Protocol instance life timeout

The number of seconds the server waits for the client’s response. This number must include the time period in which the user interacts with the device to authenticate itself.

Minimum registration assurance level

The assurance level that must be retrieved by the user before the registration of new FIDO credentials.

Do support registration

Whether or not (unchecked) this authentication method can be used for registration of new FIDO credentials.

Do support deregistration

Whether or not (unchecked) this authentication method can be used for deregistration of registered FIDO credentials.

Do support authentication

Whether or not (unchecked) this authentication method can be used for authentication with registered FIDO credentials.

Policy

The field declares what authenticator types are allowed to be used via the defined authentication method. If empty, any trusted authenticator type can be used. Otherwise, the evaluation algorithm is applied. The policies are evaluated during both registration and authentication operations. Setting up the 'Policy' attribute can be used to differentiate between different assurances levels for different authenticator types (for example, scanning an iris or using a fingerprint). This field is not applicable to the Windows Hello specification.

Do imprint trusted facets to appId

Whether the Application ID is used as is or enriched with the Facets suffix. The Application ID with imprinted trusted facets is {appId}/facets?authnMethodId={authentication method identifier} When imprint is disabled, you can configure multiple FIDO authentication methods to use the same Application ID. This field is not meaningful for Web Authentication specifications.

Allowed origins

The parameter in the client’s response that identifies the authentication-requesting application (partially determined by the 'Application ID' attribute). The value of the received parameter is compared to the values configured in the 'Allowed origins' field. If a match is not found, it may be the result of a man-in-the-middle attack and the response is discarded. This list is published in the TrustedFacets structure via Authentication Application at {location}/facets?authnMethodId={authentication method identifier}

Truststore identifier

The identifier of the truststore used by an additional mechanism for establishing a trust to the used authenticator types. This mechanism can be used when an authenticator type has no metadata propagated via the public FIDO metadata service. The authenticator type is trusted (can be used for registration and authentication operations) if its attestation certificate is present in the referenced truststore. This field is not applicable to the Windows Hello specification.

Truststore password

The password of the truststore. This field is not applicable to the Windows Hello specification.

Do require of storing credentials on the authenticator

Sets the requireResidentKey in AuthenticatorSelectionCriteria. Whether or not the FIDO service requires to create and store credentials on your authenticator. This lets you sign in without having to type your username. A record of your visit to the FIDO service will be kept on your authenticator. This is depreciated in L2 specification and residentKey should be used instead.

Storing discoverable credentials on the authenticator

Sets the residentKey flag in AuthenticatorSelectionCriteria. Specifies the extent to which the Relying Party desires to create a client-side discoverable credential. This attribute is relevant only for the Web Authentication specification. This parameter has priority over requireResidentKey, if configured the requireResidentKey flag will be derived from it.

  • required: This value indicates the Relying Party requires a client-side discoverable credential, and is prepared to receive an error if a client-side discoverable credential cannot be created.

  • preferred: This value indicates the Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential.

  • discouraged: This value indicates the Relying Party prefers creating a server-side credential, but will accept a client-side discoverable credential.

  • Allowed Values:

    • required

    • preferred

    • discouraged

Requirement of user verification on the authenticator during registration

Whether (preferred or required value) or not (discouraged value) the FIDO service requires user verification on an authenticator for the registration of new FIDO credentials. This attribute is relevant only for the Web Authentication specification.

  • Allowed Values:

    • required

    • preferred

    • discouraged

Requirement of user verification on the authenticator during authentication

Whether (preferred or required value) or not (discouraged value) the FIDO service requires user verification on an authenticator for the authentication with registered FIDO credentials. This attribute is relevant only for the Web Authentication specification.

  • Allowed Values:

    • required

    • preferred

    • discouraged

Authenticator attachment type

The Authenticator attachment parameter is used during registration phase to influence the client-side behavior. This element has only effect in WebAuthn Registration method.

  • PLATFORM: Indicates that a platform authenticator should be used. This means an authenticator which is physically bound to a client device.

  • CROSS_PLATFORM: Indicates that a roaming authenticator using cross-platform transport can be used. Such authenticators are removable from, and can roam between client devices.

  • NOT_APPLICABLE: Should be used in all other cases of FIDO authn methods types, other than WebAuthn registration method, or if you do not want to specify the attachment type during registration.

  • Allowed Values:

    • PLATFORM

    • CROSS_PLATFORM

    • NOT_APPLICABLE