Documentation

Use this guide as a reference to configuring a SAML application integration to enable Multi-Factor Authentication and Single Sign-on (SSO).

SecureAuth IdP enables both IdP- and SP-initiated SAML integrations. In IdP-initiated integrations, end-users start the login process at SecureAuth IdP and are then asserted to the application once successfully authenticated, never seeing the application's login screen. In SP-initiated integrations, end-users start the login process at the Service Provider (SP) / application, are redirected to SecureAuth IdP for authentication, and then are asserted back to the application once successfully authenticated.

This is a general SAML integration guide to assist in configuring actual application integrations. Refer to the specific application integration guide for applicable steps.

For SAML integrations that require the use of AssertionConsumerServiceIndex instead of AssertionConsumerServiceURL, there is a hotfix that includes support for AssertionConsumerServiceIndex.

For more information, see SAML integrations using AssertionConsumerServiceIndex hotfix



Prerequisites

  1. Have a SAML application and access to administrative console
  2. Create a New Realm in the SecureAuth IdP Web Admin for the SAML integration
  3. Configure the following tabs in the Web Admin before configuring the Post Authentication tab:
    • Overview – the description of the realm and SMTP connections must be defined
    • Data – an enterprise directory must be integrated with SecureAuth IdP
    • Workflow – the way in which users will access this application must be defined
    • Multi-Factor Methods – the Multi-Factor Authentication methods that will be used to access this page (if any) must be defined



SecureAuth IdP configurations

Complete the steps on the Data tab only for LDAP directory integrations. The Data tab configuration is necessary have the user ID mapped to the SecureAuth IdP in order to assert the end user to the application. 

If the application ID of the user is the same as the user ID provided to authenticate with SecureAuth IdP, then you do not need to complete the configurations on the Data tab.  

In the Membership Connection Settings section, the user ID provided to SecureAuth IdP is the directory field that equals %v in the Search Filter field. 

For example, (&(sAMAccountName=%v)(objectclass=*)) indicates the ID value stored in the sAMAccountName directory attribute is provided by the user to authenticate, and when this is the same user ID value required by the application, then no further mapping is required. 

  1. For LDAP directory integrations only, go to the Data tab. 
    To use a SQL-type data store, the mapping must be completed appropriately in the stored procedures. 
  2. In the Profile Fields section, map the the directory Field containing the user's application ID to a SecureAuth IdP Property
    For example, add the application ID field to the Email 2 property. 

  3. Save your configurations.
  4. Go to the Post Authentication tab and make the following configurations for an IdP-initiated or SP-initiated integration. 

    1. In the Post Authentication section, set the following:

      Authenticated User RedirectSet to SAML 2.0 (IdP Initiated) Assertion

      Redirect To

      The URL to which SecureAuth IdP redirects successfully authenticated end users.

      From there, SecureAuth IdP asserts end users to the application. 

    2. In the User ID Mapping section, set the following: 

      User ID Mapping

      Set to the Property containing the end user's application ID that was mapped in the Profile Fields section in step 2. 

      For example, choose Email 2 as the one used in step 2. 

      If the end user logs in to the application with the same SecureAuth IdP credentials (for example, sAMAccountName), then set to Authenticated User ID

      Name ID Format

      Keep the default unspecified option, unless the application requires a more specific option. 

      The selection varies with each application and most accept the default response. 

    3. In the SAML Assertion / WS Federation section, set the following: 

      Some fields might not be required since the SAML Assertion information varies with each application. 

      WSFed Reply To / SAML Target URL

      Set the to the absolute URL of the application, to where end users are redirected upon successful authentication.  

      This value is required for most IdP-initiated integrations. 

      SAML Consumer URL

      Set to the application URL used to accept a SAML assertion. 

      This value is not required for all integrations and is provided by the application. 

      WSFed/SAML Issuer

      Set to a unique name that identifies the SecureAuth IdP to the application (as the SAML ID).

      This value is shared with the application and can be any word, phrase, or URL, but must match exactly in the SecureAuth IdP and application configurations.

      SAML Recipient

      Set to the identifiable information of the SAML Recipient, which usually maps to the SAML Consumer URL.

      This value is not required for all integrations, and is typically the same value as the  SAML Consumer URL.

      SAML Audience

      Set to the base domain of the application.

      This value is not required for all integrations. 

      SAML Offset Minutes

      Set to make up for time differences between devices.  

      The recommended setting is 5 minutes. 

      SAML Valid Hours

      Set to how long the SAML assertion is valid. 

      The default setting is one hour, but for more sensitive application resources, the recommended value is between one to five minutes.

      Signing Cert Serial NumberLeave the default value in Signing Cert Serial Number field. Otherwise, to use a third-party certificate for the SAML assertion, click the Select Certificate link and choose the appropriate certificate.

      Assertion Signing CertificateClick the certificate link to download the signing certificate, which is then typically uploaded to the application in its configuration. 

      Domain

      Set the Domain to the SecureAuth IdP appliance URL or click the Download link to download the Metadata File, for example, https://secureauth.company.com or https://111.222.33.44.

      This value is required only if the application enables configuration via Metadata upload, otherwise no Domain value is required.

      If the application enables Metadata upload, then all of the relevant SecureAuth IdP integration information is auto-populated into the application's configuration and eliminates the need for full manual configuration.

    4. In the SAML Attributes / WS Federation section, set the following for each Attribute: 

      This section is not used in most SAML integrations. However some applications require more information to be sent over in the assertion from the directory, which can be configured in this section. 

      The values you define in this section are provided by the application. 

      NameSet to the attribute name expected by the application. 

      Namespace

      Set to the URL that communicates to the application which attribute is being asserted. 

      Format

      Set to the format in which the attribute is sent. 

      The default is Basic

      ValueSet to the Property which is mapped to the directory attribute containing the required profile information. 

    5. Save your changes. 
    6. In the Forms Auth / SSO Token section, click the View and Configure FormsAuth keys/SSO token link to configure the token/cookie settings and configure this realm for SSO.
      The token settings are preference-based; to enable SSO between applications (SAML and others), see SecureAuth IdP Single Sign-on (SSO) Configuration Guide
    1. In the Post Authentication section, set the following:

      Authenticated User RedirectSet to SAML 2.0 (SP Initiated) Assertion.
       
      Redirect To

      The URL to which SecureAuth IdP redirects successfully authenticated end users.

      From there, SecureAuth IdP asserts end users to the application. 

    2. In the User ID Mapping section, set the following: 

      User ID Mapping

      Set to the Property containing the end user's application ID that was mapped in the Profile Fields section in step 2. 

      For example, choose Email 2 as the one used in step 2.

      If the end user logs in to the application with the same SecureAuth IdP credentials (for example, sAMAccountName), then set to Authenticated User ID

      Name ID Format

      Keep the default unspecified option, unless the application requires a more specific option. 

      The selection varies with each application and most accept the default response. 

    3. In the SAML Assertion / WS Federation section, set the following: 

      For a typical SP-initiated integration, the SP handles most of the integration values and some fields might not be required. 

      WSFed/SAML Issuer

      Set to a unique name that identifies the SecureAuth IdP to the application (as the SAML ID).

      This value is shared with the application and can be any word, phrase, or URL, but must match exactly in the SecureAuth IdP and application configurations.

      SP Start URL

      Set to the login URL for the application.

      This value enables appropriate redirection for normal login and SSO login experiences.

      SAML Offset Minutes

      Set to make up for time differences between devices.  

      The recommended setting is 5 minutes. 

      SAML Valid Hours

      Set to how long the SAML assertion is valid. 

      The default setting is one hour, but for more sensitive application resources, the recommended value is between one to five minutes.

      Signing Cert Serial NumberLeave the default value in Signing Cert Serial Number field. Otherwise, to use a third-party certificate for the SAML assertion, click the Select Certificate link and choose the appropriate certificate.

      Assertion Signing CertificateClick the certificate link to download the signing certificate, which is then typically uploaded to the application in its configuration. 

      Domain

      Set the Domain to the SecureAuth IdP appliance URL or click the Download link to download the Metadata File, for example, https://secureauth.company.com or https://111.222.33.44.

      This value is required only if the application enables configuration via Metadata upload, otherwise no Domain value is required.

      If the application enables Metadata upload, then all of the relevant SecureAuth IdP integration information is auto-populated into the application's configuration and eliminates the need for full manual configuration.

    4. In the SAML Attributes / WS Federation section, set the following for each Attribute: 

      This section is not used in most SAML integrations. However some applications require more information to be sent over in the assertion from the directory, which can be configured in this section. 

      The values you define in this section are provided by the SP/application. 

      NameSet to the attribute name expected by the application. 

      Namespace

      Set to the URL that communicates to the application which attribute is being asserted. 

      Format

      Set to the format in which the attribute is sent. 

      The default is Basic

      ValueSet to the Property which is mapped to the directory attribute containing the required profile information. 

    5. Save your changes. 
    6. In the Forms Auth / SSO Token section, click the View and Configure FormsAuth keys/SSO token link to configure the token/cookie settings and configure this realm for SSO.
      The token settings are preference-based; to enable SSO between applications (SAML and others), see SecureAuth IdP Single Sign-on (SSO) Configuration Guide

To configure the token/cookie settings for this realm

  1. In the Forms Authentication section, set the following: 

    Require SSLIf SSL is required to view the token, set to True

    Cookieless

    Select whether SecureAuth IdP is to deliver the token in a cookie to the user's browser or device: 

    • UseCookies – Enables SecureAuth IdP to always deliver a cookie
    • UseUri – Disables the delivery of a cookie by SecureAuth IdP.  Instead, deliver the token in a query string
    • AutoDetect – Enables SecureAuth IdP to deliver a cookie, if the user settings allow it
    • UseDeviceProfile – Enables SecureAuth IdP to deliver a cookie, if the browser settings allow it, regardless of the user settings.

    Sliding ExpirationSet to True to have the cookie remain valid as long as the user is interacting with the page. 

    Timeout

    Indicate in minutes how long a cookie is valid. 

  2. In the Machine Key section, set the following: 

    ValidationVerify whether the default value (SHA1) matches your configuration requirement. Otherwise, select another value. 

    Decryption

    Verify whether the default value (Auto) matches your configuration requirement. Otherwise, select another value. 

  3. In the Authentication Cookies section, set the following: 

    Persistent

    Set to one of the following: 

    • True - Expires after Timeout – Cookie remains valid until the length of the Timeout is met. 
    • False - Session Cookie – Cookie remains valid until the browser closes or the session expires. 

  4. Save your changes. 

Other SSO configuration options

To configure this realm for SSO, see SecureAuth IdP Single Sign-on (SSO) Configuration Guide.

To configure this realm for Windows Desktop SSO, see Windows desktop SSO configuration