11.2.4 Creating a SAML 2.0 Event

You can create this event for third-party integrations with SAML 2.0.

To create an SAML 2.0 event, perform the following steps:

  1. Click Events > Add.

  2. Specify a name for the event.

  3. Set Is enabled to ON.

  4. Select SAML 2 in the Event type.

  5. Select the Authenticator category. The Authenticator category option is displayed only if you have added categories in the Event Categories policy.

  6. Select the chains that you want to assign to the current event.

    The top chain (first chain) in the list of selected chains will be considered as a high-priority or high-security chain for that specific event.

  7. Set the Enable chain selection with one of the following options on your requirements:

    • ON: Select this option to allow users to select their preferred authentication chain from all the chains that are available to them. By default, this option is set to ON.

    • OFF: Select this option to force users to use the chain that has the highest priority for authentication.

    • OPTIONAL: Select this option to display the high-priority chain with the ability to select the other chains from the list. If the user doesn’t wish to continue with the highest priority chain, they can click the Select Chain button to select their preferred chain from all the chains that are available to them.

  8. (Conditional) In Risk Policy, select the policy that you want to assign to this event for assessing the risk associated with a login attempt.

  9. (Conditional) Click Create New Policy to create a new risk policy for this event.

    Clicking this option opens the Risk Settings page.

    IMPORTANT:Risk Policy and Create New Policy options are available when you enable Risk Settings. For more information, see Section III, Configuring Risk Settings.

  10. In SAML 2.0 settings, perform the following actions:

    NOTE:You must configure the Web Authentication policy for the SAML 2.0 event to work appropriately.

    1. You can either insert your Service Provider's SAML 2.0 metadata in SP SAML 2.0 metadata or click Browse and select a Service Provider's SAML 2.0 metadata XML file to upload it.

    2. Select the required option from NameID formatting options based on the SAML response requirement of service provider. The available options are:

      • Use default: To send NameID in SAML response without any customization.

      • Send E-Mail as NameID (suitable for G-Suite): To send email address in the NameID attribute and is required for integrating with the G-suite.

      • Send SAMAccount as NameID: To send SAMAccountName in the NameID attribute of SAML response from the Advanced Authentication server.

      • Send CN as NameID: To send UID of user in the NameID attribute of SAML response from the Advanced Authentication server. This is required, when eDirectory is used as the repository and service providers want nameid format as unspecified however need Common Name (UID by default) in the SAML response. This is required for integrating with Cyberark.

      • Send ImmutableId (User objectId) as NameID (required for Microsoft Office 365): To send User objectId in the NameID attribute as a SAML response from the Advanced Authentication server. This is required for integrating with Microsoft Office 365.

      • Create Custom NameID: To send custom details about user, such as Windows domain qualified name, unspecified and so on in the NameID attribute as a SAML response.

        For sending custom details in NameID attribute, perform the following:

        • Select the preferred NameID Format to send in the SAML response. The available options are:

          • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

          • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

          • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName

          • urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName

          • urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos

        • Specify the attribute that you want as identifier in the SAML response.

          Some attributes that do not need additional configurations are DN, CN, mail, mobile, sid, upn, netbiosname, sAMAccountName, and userImmutableID. Other attributes that are not in the list must be configured in the LDAP repository’s Custom attributes to fetch and Custom attributes to return.

        To customize LDAP attributes in the SAML assertion, see Customizing LDAP Attributes in the SAML Assertion.

    3. Specify the Attribute Maps in Attribute Maps. One Map per line.

      The Attribute maps should be specified in the following format:

      localName="<local name>" samlName="<Service Provider name>"

      For example,

      localName="mail" samlName="e-mail address"

      Here, the service provider expects the "e-mail address" instead of "mail" from the Identity Provider (in this case, Advanced Authentication).

      localName="userLastName" samlName="Surname"

      localName="userFirstName" samlName="Given Name"

      localName="mobile" samlName="Telephonenumber"

      where,

      • localName: This value indicates the name of the attribute in the Web Authentication (local) namespace. This is how it is referred in Advanced Authentication. This value can be defined by users.

      • samlName: This value indicates the name of the attribute in SAML assertion.

    4. Set Logon with Expired Password with one of the following options based on your requirement:

      • Allow: Select this option to allow users to log in to the event with the expired LDAP password.

      • Ask to change: If the password has expired this option prompts users to change the password during logon. Change in the LDAP Password is supported only for the Active Directory repositories. However, the LDAP Password change in Advanced Authentication is not allowed when the LDAP Servers in the Repository settings are configured with port 389. The LDAP server rejects the new password.

      • Deny: Select this option to deny access to the event with the expired LDAP password. When the access is denied, the following message is displayed to users:

        You must change your password to logon.

    5. Set Bypass user lockout in repository to ON, users, who are locked in the repository, must select and authenticate with the chain that does not include the LDAP Password method. By default, Bypass user lockout in repository is set to OFF and locked users cannot authenticate by using any chain.

      To use this functionality, it is required to have more than one chain without the LDAP Password method assigned to the event. This is to provide more options to users.

      NOTE:All authentication chains irrespective of whether it includes the LDAP Password method or not are displayed to users who are locked in the repository.

    6. Set Allow token re-use to ON, if you want to allow users to apply the OTP multiple times within the Allow re-sending after (seconds) duration for authentication. This option is applicable for Email OTP, SMS OTP, and Voice OTP methods.

      By default, Allow token re-use is set to OFF and users are not allowed to apply the OTP more than once within the Allow re-sending after (seconds) duration that has been set for Email OTP, SMS OTP, and Voice OTP methods.

    7. Set Return groups on logon to ON to retrieve the group details of users who authenticated to the SAML 2.0 event in the authentication response.

      With Return groups on logon set to ON, if Groups is empty, all the groups that the users are associated with are returned in the response. However, to return the required groups, specify the preferred groups in Groups.

      By default, this option is set to OFF, the groups of users authenticated to the event are not returned in the response.

    8. Select the Allow to logon to this event by shared authenticator option to allow users to login using shared authenticators. By default this option is disabled for the Authenticators Management, Helpdesk, Helpdesk User, AdminUI, Search Card, Token Management, and Report Logon events and enabled for all the other events.

      NOTE:The Allow to logon to this event by shared authenticator option is displayed if you enable the Enable sharing of authenticators option in Authenticator Management Options policy.

    9. A top administrator can enforce the configuration of events (except the RADIUS Server event) on secondary tenants. For more information, see Step 18.

  11. Click Save.

SAML events support the step-up authentication. It does not prompt users to authenticate with the same method that is succeeded for an event during the session. Let us understand the step-up authentication with an example, assume there are three SAML events, SMEVT1, SMEVT2, and SMEVT3. Chains associated with each event are as follows:

  • SMEVT1 - LDAP Password + Security Questions

  • EVT2 - LDAP Password + SMS OTP

  • EVT3 - Security Questions + SMS OTP

Possible scenarios:

  • First the user logs in to SMEVT1 by furnishing LDAP password and valid secret questions. During the same session if the user tries to authenticate to SMEVT3 then a prompt to provide the SMS OTP is displayed. This happens because user has succeeded Security Questions method for SMEVT1.

  • User logs in to SMEVT3 first with the Security Questions and SMS OTP. Later, the user can authenticate to SMEVT2 with the LDAP Password method because SMS OTP is succeeded in the previous event.