Unsupported content This version of the product is in limited support. However, the documentation is available for your convenience. You will not be able to leave comments.

Authentication chaining

Remedy Single Sign-On supports authentication chaining as a fallback mechanism. Authentication chaining ensures that when the primary authentication fails, Remedy SSO invokes alternate authentication methods. The authentication failure can be due to an incorrect user name or password or due to unavailability of the Identity Provider (IdP) server.

Example

You can use the authentication chaining feature in a scenario where a user who is in the domain needs to log in automatically to the system using Kerberos and the same user needs to log in to the system using username and password when out of the domain.

Related topics

Configuring-realms

Considerations before configuring authentication chaining

  • While configuring the authentication chain, do not specify an IdP twice because the system executes the authentication chain sequentially and specifying an IdP twice might result in a loop.
  • BMC does not recommend using Kerberos and certificate-based authentication types for chaining because some browsers, such as Firefox, have special restrictions related to the integrated authentication. The restriction requires that a machine with Remedy SSO must be in a whitelist to manage the Kerberos authentication type.

Supported authentication chaining

The following table lists the authentication types and other authentications with which you can chain them.

First authentication type

Valid fallback authentication types

AR

  • AR
  • LDAP
  • LOCAL

CERT

  • AR
  • LDAP
  • LOCAL
  • SAML

KERBEROS

  • AR
  • LDAP
  • LOCAL
  • SAML

LDAP

  • AR
  • LDAP
  • LOCAL

LOCAL

  • AR
  • LDAP

SAML

  • LOCAL

Note: if SAML is the first authentication and LOCAL is the second in the chain, fallback is used for retrieving user groups.

PREAUTH

  • AR
  • LOCAL
  • LDAP
  • SAML

Authentication chaining flow

Stage

Description

1

The system checks whether the first IdP is SAML or non-SAML:

  • SAML IdP: Forward the request to the SAML login module. If the authentication fails, the IdP login page shows the error message. If the authentication succeeds, Remedy SSO creates a user session, sets the cookie domain, and logs in the user.
  • Non-SAML IdP: Forward the request to the non-SAML login module. Go to Stage 2.

2

If authentication fails, check whether the next IdP is SAML or non-SAML:

  • SAML IdP: Forward the request to the SAML login module. If the authentication fails, the IdP login page shows the error message. If the authentication succeeds, Remedy SSO creates a user session, sets the cookie domain, and logs in the user.
  • Non-SAML IdP: Invoke the IdP's authenticate method to verify the authentication request. Go to Stage 3.

3

 

  • Authentication succeeds: Generate user session and set the domain cookie.
  • Authentication fails: Go to stage 2.

If authentication fails at all IdPs and there is no LDAP, AR, or LOCAL authentication defined in the chain, the system shows an authentication failure message. Otherwise, the system shows an error message on the Remedy SSO login page and prompts the user to retry.

Reauthentication

If the authentication chain is configured as Kerberos or a certificate-based authentication as the first authentication method and LDAP/AR/LOCAL IdP as the reauthentication method, users are required to provide a user name and password at the time of reauthentication even though they might not have provided either earlier while getting authenticated through Kerberos or the certificate-based authentication.

If the authentication type is simply Kerberos or a certificate-based authentication or the authentication chain contains only the Kerberos or certificate-based authentication, users are reauthenticated automatically.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*