Composite Authentication Method

The composite authentication method enables the combination of multiple standalone authentication methods. This method can define the order of these methods and the conditional steps between them (based on success and failure). With respect to the Authentication Application, the configuration of this method includes defining the methods to be prompted to the user at a single page.

Within the Authentication Application, the composite authentication method supports following scenarios:

Any standalone authentication methods except SAML- and OAuth-based methods.
Any combination with each authentication method invoked on a separate page.
Combinations with multiple authentication methods invoked on a single page as long as the methods allow it (for example, HTTP form and one-time password). In this case, some authentication parameters can be omitted for a better user experience.

Each Authentication Method on a Separate Page

Any combination with each authentication method invoked on a separate page means that for each step there is a challenge whose result is independently verified and correlated. Successful verification and correlation of a step can then continue to the next step or authentication can pass based on a disjunctive or conjunctive configuration.

Disjunctive configuration

The disjunctive configuration means that the authentication is successful if at least one of the steps is successful.

attachments/disjunctive-consecutive-authentication

Figure 1. Diagram depicting disjunctive consecutive configuration

The actor is redirected to proceed with composite authentication.
The actor is prompted to enter credentials for the first step, which is on the first page. The challenge can be also hidden for the actor, for example in case of the Kerberos authentication method.
The actor enters the credentials for the first step.
- In case of success, the composite authentication is successful and the actor is redirected to the protected resource.
In case of failure, the actor is prompted to enter credentials for the second step, which is on the second page.
The actor enters the credentials for the second step.
- In case of success, the composite authentication is successful and the actor is redirected to the protected resource.
- In case of failure, the authentication fails and the actor is redirected to the retry page.

Please see the following example of disjunctive configuration:

{
  "dp": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethodComposite",
  "key": "Disjunctive Consecutive Authentication",
  "type": "composite",
  "compositeSteps": [
    {
      "page": 1,
      "stepNumber": 1,
      "successAction": "Pass",
      "failureAction": "Continue",
      "failureJump": 2,
      "authnMethodId": {
        "key": "Kerberos Authentication",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }, {
      "page": 2,
      "stepNumber": 2,
      "successAction": "Pass",
      "failureAction": "Fail",
      "authnMethodId": {
        "key": "Kerberos Authentication",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }
  ]
}

Conjunctive configuration

The conjunctive configuration means that the authentication is successful if all steps are successful.

attachments/conjunctive-consecutive-authentication

Figure 2. Diagram depicting conjunctive consecutive configuration

The actor is redirected to proceed with composite authentication.
The actor is prompted to enter credentials for the first step, which is on the first page. The challenge can be also hidden for the actor, for example in case of the Kerberos authentication method.
The actor enters the credentials for the first step.
- In case of failure, the actor is prompted to repeat the credentials for the first step (B).
In case of success, the actor is prompted to enter credentials for the second step, which is on the second page.
The actor enters the credentials for the second step.
- In case of success, the composite authentication is successful and the actor is redirected to the protected resource.
- In case of failure, the actor is prompted to repeat the credentials for the second step (D).

Please see the following example of conjunctive configuration:

{
  "dp": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethodComposite",
  "key": "Conjunctive Consecutive Authentication",
  "type": "composite",
  "compositeSteps": [
    {
      "page": 1,
      "stepNumber": 1,
      "successAction": "Continue",
      "successJump": 2,
      "failureAction": "Continue",
      "failureJump": 1,
      "authnMethodId": {
        "key": "Kerberos Authentication",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }, {
      "page": 2,
      "stepNumber": 2,
      "successAction": "Pass",
      "failureAction": "Continue",
      "failureJump": 2,
      "authnMethodId": {
        "key": "Kerberos Authentication",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }
  ]
}

Please notice the explicit configuration of "failureAction" to continue with the same step in case of failure.

Authentication Methods with Multiple Verification and Correlation on a Single Page

The composite authentication method can be used to define a sequence of authentication methods of the same type on a single page. In this case, the sequence means that there is one challenge whose result is verified and correlated with multiple authentication methods in disjunctive configuration.

The disjunctive configuration means that the authentication is successful if at least one of the steps is successful.

attachments/multiple-same-type-authentication

Figure 3. Diagram depicting multiple configuration of the same type on the same page

The actor is redirected to proceed with composite authentication.
The actor is prompted to enter credentials for all subsequent steps.
The actor enters the credentials. The credentials are verified and correlated with all subsequent steps.
- In case of success in the first step, the composite authentication is successful and the actor is redirected to the protected resource.
- In case of failure in the first step, the same credentials are verified and correlated with the second step.

Please see the following example:

{
  "dp": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethodComposite",
  "key": "Multiple Authentication",
  "type": "composite",
  "compositeSteps": [
    {
      "page": 1,
      "stepNumber": 1,
      "successAction": "Pass",
      "failureAction": "Continue",
      "failureJump": 2,
      "authnMethodId": {
        "key": "Kerberos Authentication with realm correlation",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }, {
      "page": 1,
      "stepNumber": 2,
      "successAction": "Pass",
      "failureAction": "Fail",
      "authnMethodId": {
        "key": "Kerberos Authentication with principal correlation",
        "type": "net.atos.dirx.access.apprepo.api.config.authn.method.AuthnMethod"
      }
    }
  ]
}

Multiple Authentication Methods of Different Types on a Single Page

To some extent, the authentication application allows to configure multiple authentication methods of different types on a single page. For example, the Form authentication method can be combined with One-Time-Password authentication methods (RFC 4226, RFC6238 or OTP callback). In this case, the challenges for both methods are presented to the actor on the same page, and the actor can enter credentials for both methods at once.

attachments/multiple-different-type-authentication

Figure 4. Diagram depicting multiple configuration of different types on the same page

The actor is redirected to proceed with composite authentication.
The actor is prompted to enter credentials for all subsequent steps.
The actor enters the credentials. The credentials are verified and correlated with all subsequent steps. It is important to note that not all credentials are valid for all steps and, on the other hand, some credentials may overlap.
- In case of success in the first step, the credentials are verified and correlated with the second step.
- In case of failure in the first step, the actor is prompted to repeat the credentials for all subsequent steps (B).
- In case of success in the second step, the composite authentication is successful and the actor is redirected to the protected resource.
- In case of failure in the second step, the actor is prompted to repeat the credentials for all subsequent steps (B).

X.509 Authentication in Composite Authentication

The X.509 authentication utilizes the client certificate added to the X-SSL-CERT header during the SSL/TLS handshake. However, this handshake can only occur when the client first accesses the port.

When configuring X.509 as one of possible authentication methods in an authentication applications selection, a separate authentication application on a different port can be used to prompt the user to authenticate to the server with their SSL certificate.

It is also possible to use redirection to second authentication application to use X.509 authentication as one of the steps in composite authentication.

Configuring a Load Balancer

Create a new port on your load balancer where the second authentication application with X.509 will run. Enable SSL client verification on this port. After the SSL handshake, the load balancer should set the X-SSL-CERT header to the value of client certificate. For example for Nginx this would look like this: proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;.

Example of the configuration in Nginx can be seen here: Client TLS Authentication for Request Resolution.

Adding the Port Assignment

Add the port assignment for this new port in Servers → Port assignment.

To accept the X.509 certificate from the X-SSL-CERT header check the "Do client certificate from proxy request header resolution" checkbox, also check "Do verify proxy request resolution" checkbox and select a "Proxy truststore identifier" to verify the client certificate.

Also add the new port to “Servers → Servers → your DXA server → Server communication → Port assignment identifiers”.

Example of the port configuration in DirX Access Manager is shown below.

Figure 5. Example of a new port assignment for second authentication application

Setting up Composite Authentication with X.509 Authentication

In composite authentication an Authentication Application can be used as one of the steps. This will result in a redirection to the application during authentication. This can be used to redirect to a different application to prompt the user to authenticate with his certificate and then back to the original one where the rest of the authentication can be done.

How an Authentication Application can be used to enable X.509 authentication in composite authentication is described below.

Create a new Authentication application in “Authentication → Applications”. This application will be used as redirection and to verify the user with X.509 method.
Create an authentication method that points to this new application in “Authentication → Methods → Authentication application”.
Create a new composite method.
1. For redirection to different application use authentication method “Authentication application” as a step, this will redirect the user to that application and continue in the composite authentication.
2. If you need to redirect clients back to the original application after the X.509 authentication, you can do so by adding the original “Authentication application” method as a next step.
3. If X.509 is the last method (or the last one just before redirecting to the original application), specify the “User account correlation” to correspond to the “User account correlation” in the X.509 method(so the server can correctly link the certificate to the user in LDAP), you would do so for other methods that have this option, as for example OAuth.
Add the new composite authentication method to the selection of your main authentication application.
Deploy the new authentication application in “System actions → Deployment → Web → Application”.
Restart the server and test your method.