Documentation

Introduction

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.

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
  • Registration Methods / Multi-Factor Methods – the Multi-Factor Authentication methods that will be used to access this page (if any) must be defined
SecureAuth IdP Configuration Steps
Data

This step is required for LDAP directory integrations only

If using a SQL-type data store, then the mapping must be completed appropriately in the stored procedures

 

It is necessary to have the user ID mapped to SecureAuth IdP in order to assert the end-user to the application

1. In the Profile Fields section, map the directory field that contains the user's application ID to a SecureAuth IdP Property

For example, add the application ID field to the Email 2 Property if it is not already contained somewhere else

If the user's application ID is the same as the user ID provided to authenticate with SecureAuth IdP, then this step is not necessary

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

For example, (&(sAMAccountName=%v)(objectclass=*)) tells SecureAuth IdP that the user provides the ID value stored in the sAMAccountName directory attribute to authenticate; and if that is the same user ID value that the application requires, then no further mapping is required

Click Save once the configurations have been completed and before leaving the Data page to avoid losing changes

Post Authentication

Below are example configurations for both IdP- and SP-initiated SAML integrations

Applications may support only one option or both, so the integration may depend on the application's abilities

 

2. Select SAML 2.0 (IdP Initiated) Assertion from the Authenticated User Redirect dropdown

3. The Redirect To field auto-populates with the URL to which SecureAuth IdP redirects successfully authenticated end-users

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

User ID Mapping

4. Select the Property that contains the end-user's application ID, e.g. Email 2 based on the mapping completed in step 1 from theUser ID Mapping dropdown

If the end-user logs into the application with the same SecureAuth IdP credentials (e.g. sAMAccountName), then select Authenticated User ID

 Example Image

5. Keep the Name ID Format as the default unspecified option, unless the application requires a more specific option

This selection varies per application, but most accept the default response

SAML Assertion / WS Federation

The SAML Assertion information varies per application, so not all fields may be required

6. Set the WSFed Reply To / SAML Target URL 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

7. Set the SAML Consumer to the SP-provided URL that is used to accept a SAML assertion

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

8. Set the WSFed/SAML Issuer to a unique name that identifies the 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 on on the IdP and application configurations

9. Set the SAML Recipient 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

10. Set the SAML Audience to the base domain of the application

This value is not required for all integrations

11. Set the SAML Offset Minutes to make up for time differences between devices

SecureAuth recommends 5 minutes

12. Set the SAML Valid Hours to the validity period of the SAML assertion

SecureAuth recommends 1 hour

No configuration is required for the SP Start URL field

13. Leave the Signing Cert Serial Number as the default SecureAuth IdP certificate, unless using a third-party certificate for the SAML integration

If using a different certificate, then that certificate must be uploaded onto the SecureAuth IdP appliance's certificate store, and can be selected by click Select Certificate

14. Click to download the Assertion Signing Certificate, which is typically uploaded to the application in its configuration

15. Set the Domain to the SecureAuth IdP appliance URL or IP Address to Download the Metadata File, e.g. 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

SAML Attributes / WS Federation

Some applications required additional information to be sent over in the assertion from the directory, which can be configured in this section

This section is not used in most SAML integration configurations

16. Set the Name of Attribute 1 to attribute name expected by the application

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

18. Select the Format in which the attribute is sent from the dropdown

This value is typically Basic (default)

19. Select the Property that is mapped to the directory attribute that contains the required profile information from the Value dropdown

20. Repeat the steps for each attribute required

The values required for steps 16 - 20 are all provided by the SP

Click Save once the configurations are complete and before leaving the Post Authentication page to avoid losing changes

Forms Auth / SSO Token

21. Click View and Configure Forms Auth Keys / SSO Token to configure the realm's token settings and to enable SSO

The token settings are all preference-based; but follow the SecureAuth IdP Single Sign-on Configuration Guide to enable SSO between applications (SAML and others)

 To configure this realm's token/cookie settings, follow these steps:
Forms Authentication

 

1. If SSL is required to view the token, select True from the Require SSL dropdown

2. Choose whether SecureAuth IdP will deliver the token in a cookie to the user's browser or device:

  • UseCookies enables SecureAuth IdP to always deliver a cookie
  • UseUri disables SecureAuth IdP to deliver a cookie, and instead deliver the token in a query string
  • AutoDetect enables SecureAuth IdP to deliver a cookie if the user's settings allow it
  • UseDeviceProfile enables SecureAuth IdP to deliver a cookie if the browser's settings allow it, no matter the user's settings

3. Set the Sliding Expiration to True if the cookie remains valid as long as the user is interacting with the page

4. Set the Timeout length to determine for how many minutes a cookie is valid

No configuration is required for the Name, Login URL, or Domain fields

Machine Key

 

5. No changes are required in the Validation field, unless the default value does not match the company's requirement

If a different value is required, select it from the dropdown

6. No changes are required in the Decryption field, unless the default value does not match the company's requirement

If a different value is required, select it from the dropdown

No configuration is required for the Validation Key or Decryption Key fields

Authentication Cookies

 

7. Enable the cookie to be Persistent by selecting True - Expires after Timeout from the dropdown

Selecting False - Session Cookie enables the cookie to be valid as long as the session is open, and will expire once the browser is closed or the session expires

No configuration is required for the Pre-Auth Cookie, Post-Auth Cookie, or the Clean Up Pre-Auth Cookie fields

Click Save once the configurations have been completed and before leaving the Forms Auth / SSO Token page to avoid losing changes

To configure this realm for SSO, refer to SecureAuth IdP Single Sign-on Configuration

To configure this realm for Windows Desktop SSO, refer to Windows desktop SSO configuration

 

2. Select SAML 2.0 (SP Initiated) Assertion from the Authenticated User Redirect dropdown

3. The Redirect To field auto-populates with the URL to which SecureAuth IdP redirects successfully authenticated end-users

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

User ID Mapping

4. Select the Property that contains the end-user's application ID, e.g. Email 2 based on the mapping completed in step 1 from theUser ID Mapping dropdown

If the end-user logs into the application with the same SecureAuth IdP credentials (e.g. sAMAccountName), then select Authenticated User ID

 Example Image

5. Keep the Name ID Format as the default unspecified option, unless the application requires a more specific option

This selection varies per application, but most accept the default response

SAML Assertion / WS Federation

The SAML Assertion information varies per application, so more fields may be required; but for typical SP-initiated integrations, the SP handles most of the integration values

6. Set the WSFed/SAML Issuer to a unique name that identifies the 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 on on the IdP and application configurations

7. Set the SP Start URL to the application's login URL

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

8. Set the SAML Offset Minutes to make up for time differences between devices

SecureAuth recommends 5 minutes

9. Set the SAML Valid Hours to the validity period of the SAML assertion

SecureAuth recommends 1 hour

In typical integrations, no configuration is required for most of the fields

10. Leave the Signing Cert Serial Number as the default SecureAuth IdP certificate, unless using a third-party certificate for the SAML integration

If using a different certificate, then that certificate must be uploaded onto the SecureAuth IdP appliance's certificate store, and can be selected by click Select Certificate

11. Click to download the Assertion Signing Certificate, which is typically uploaded to the application in its configuration

12. Set the Domain to the SecureAuth IdP appliance URL or IP Address to Download the Metadata File, e.g. 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

SAML Attributes / WS Federation

Some applications required additional information to be sent over in the assertion from the directory, which can be configured in this section

This section is not used in most SAML integration configurations

13. Set the Name of Attribute 1 to attribute name expected by the application

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

15. Select the Format in which the attribute is sent from the dropdown

This value is typically Basic (default)

16. Select the Property that is mapped to the directory attribute that contains the required profile information from the Value dropdown

17. Repeat the steps for each attribute required

The values required for steps 13 - 17 are all provided by the SP

Click Save once the configurations are complete and before leaving the Post Authentication page to avoid losing changes

Forms Auth / SSO Token

18. Click View and Configure Forms Auth Keys / SSO Token to configure the realm's token settings and to enable SSO

The token settings are all preference-based; but follow the SecureAuth IdP Single Sign-on Configuration Guide to enable SSO between applications (SAML and others)

 To configure this realm's token/cookie settings, follow these steps:
Forms Authentication

 

1. If SSL is required to view the token, select True from the Require SSL dropdown

2. Choose whether SecureAuth IdP will deliver the token in a cookie to the user's browser or device:

  • UseCookies enables SecureAuth IdP to always deliver a cookie
  • UseUri disables SecureAuth IdP to deliver a cookie, and instead deliver the token in a query string
  • AutoDetect enables SecureAuth IdP to deliver a cookie if the user's settings allow it
  • UseDeviceProfile enables SecureAuth IdP to deliver a cookie if the browser's settings allow it, no matter the user's settings

3. Set the Sliding Expiration to True if the cookie remains valid as long as the user is interacting with the page

4. Set the Timeout length to determine for how many minutes a cookie is valid

No configuration is required for the Name, Login URL, or Domain fields

Machine Key

 

5. No changes are required in the Validation field, unless the default value does not match the company's requirement

If a different value is required, select it from the dropdown

6. No changes are required in the Decryption field, unless the default value does not match the company's requirement

If a different value is required, select it from the dropdown

No configuration is required for the Validation Key or Decryption Key fields

Authentication Cookies

 

7. Enable the cookie to be Persistent by selecting True - Expires after Timeout from the dropdown

Selecting False - Session Cookie enables the cookie to be valid as long as the session is open, and will expire once the browser is closed or the session expires

No configuration is required for the Pre-Auth Cookie, Post-Auth Cookie, or the Clean Up Pre-Auth Cookie fields

Click Save once the configurations have been completed and before leaving the Forms Auth / SSO Token page to avoid losing changes

To configure this realm for SSO, refer to SecureAuth IdP Single Sign-on Configuration

To configure this realm for Windows Desktop SSO, refer to Windows desktop SSO configuration

  • No labels