First, the first authenticator is called. If authentication with the first authenticator succeeds (or only a password change is enforced), the second authenticator is called. The second authenticator can also depend on user data. Therefore a user dependent second authentication step can be achieved.
Example: Username and password verification in the first step and token verification in the second step for user A but challenge-response authentication for user B.

The first authenticator must be one that accepts credentials with a user name (UserCredential or subclass).
The second authenticator is then called for the first time with the credential that was passed to the first authenticator in the first step. This is always a credential with a user name.

The overall authentication is considered to be successful if (and only if) the first authentication step succeeds (or a password change is required) and the second authentication step succeeds. The resulting authentee returned with the successful authentication result is a combination of the results from both authenticators. The set of roles contains both roles from the first and the second authenticator. The context data container contains both the data from the first and the second authenticator. If a key in the context data container is used in both the results from the first and the second authenticators, then the value from the second authenticator's result overwrites the one from the first. If the first and the second authenticators provide a different user name in the authentee object, the one from the second authenticator is used.

Be careful when using authenticator plug-ins that automatically adjust user information after successful or failed authentication. If an authenticator, for example, resets the number of failed logins after successful authentication, it will not produce what you want when used as first authenticator. It would reset the number of failed logins even if the second authentication step fails. Most authenticators provided by Airlock IAM allow to turn off automatic used data updates for this purpose. Make sure to configure them accordingly when using them as part of a bigger authentication process with this plug-in.

Typical example application: Check username and password against a directory or database and then check a third credential (token, smart card, matrix card) with a separate, used-dependent authentication mechanism.

For the configured authenticator plugins used in the second step, a channel-prefix can be configured (optionally). If configured, this prefix is prepended to the current channel when loading the plugins. This is useful for example when two authentiators use the same plugin with different configuration sets or if the an authenticator plugin is used multiple times with a different configuration.

If a user persister is configured (this is mandatory if different second authenticator plugins are configured), it is also consulted to check whether the user is locked or if a password change is required after the first authenticator said ok. This is useful if the first authenticator does not support these concepts.

The plugin writes the canonical class name description (including packages) of the authenticator plugin used in the second step into the context data container of the authentication result. The information is written into the context data container as soon as the second authenticator is defined (i.e. after successful authentication with first authenticator). The class name is stored under the key authPluginClassName
A short description of the second authentication method (and only the second one) is stored under the key authMethodShortDesc . This information may be used by callers.

type: MetaAuthenticator
id: MetaAuthenticator-xxxxxx
displayName: 
comment: 
properties:
  additionalUserValidators:
  defaultSecondAuthenticator:
  displayLastLoginTimestamp: false
  first:
  maxFailedLogins: 5
  secondAuthenticatorSelector:
  secondAuthenticatorsByAuthMethod:
  useUsernameFromUserPersister: true
  userPersister: