Documentation

Introduction

SecureAuth's SAML Multi-tenant Consumer feature transforms SecureAuth IdP into a Service Provider (SP) that consumes SAML assertions from one or multiple Identity Providers in a single SecureAuth IdP realm.

Administrators can configure a realm to accept multiple SAML assertions that will then be asserted by SecureAuth IdP to the designated post-authentication event, creating a more user-friendly user and administrator experience.

Prerequisites

1. Have an Identity Provider (or multiple) that can generate a SAML assertion to SecureAuth IdP

2. Obtain the Identity Provider's SAML Certificate and Issuer Value; or the Identity Provider's Metadata File to use in the configuration

SecureAuth IdP Configuration Steps
Data

 

1. In the Membership Connection Settings section, select No Data Store from the Data Store dropdown

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

Workflow

 

2. In the SAML Consumer section, click Add Identity Provider to include an IdP

Add Identity Provider

3. Provide the Identity Provider Name, which is a friendly name that appears in the SAML Consumer section

4. Provide the SAML Issuer from the IdP's SAML certificate

5. Copy the contents of the certificate and paste it into the Signing Certificate field; or click Choose File and select the IdP's metadata file, which will complete the form

6. Click Add and Save

 

The new Identity Provider appears in the SAML Consumer section, where it can be Edited at any point

7. Repeat steps 2-6 for additional Identity Providers to be added

Clicking the arrow in the Edit button and selecting Generate SP Meta File creates a file with attribute information as well as the AssertionConsumerService Location

Generating this file provides the exact URL for reference, or format the URL as https://<SecureAuthIdPFQDN>/<SecureAuthRealm#>/AssertionConsumerService.aspx

For example: https://secureauth.company.com/secureauth5/AssertionConsumerService.aspx

If previously utilizing SecureAuth IdP as a SAML Consumer, then please note that the consumer endpoint has changed from /SAML20IdPInitACS.aspx to /AssertionConsumerService.aspx (see note above)

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

Post Authentication

 

8. In the Forms Auth / SSO Token section, click View and Configure Forms Auth keys / SSO token

Forms Authentication

 

9. Set the Name of the FBA token to any name

Authentication Cookies

 

10. Set the Post-Auth Cookie name to the same token name set in step 9

The FBA Token Name and the Post-Auth Cookie Name must match in realms utilizing the SAML Multi-tenant Consumer

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

Enable SAML Condition Checking

The configuration steps below should be performed for realms that are configured in a Service Provider (“SAML Consumer”) role in which the realm accepts SAML assertions from third-party Identity Providers

These settings are necessary in order to enable condition checking for SAML assertions

Realms configured in this manner have Identity Providers listed in the SAML Consumer section of the Workflow tab

1. On the realm configured in a Service Provider (SP) role, open the Web Admin

2. Navigate to the System Info tab > Links section and open the Click to edit Web Config file link

 

 

3. In the Web Config Editor, locate the issuer= string, which is under the certificate for the configured Identity Provider

  • Example: issuer="http://host.example.com/trust" />

4. Click to expand the appropriate set of instructions below

 For Identity Providers that are sending SAML WITH conditions, click here

4a. For Identity Providers that are sending SAML WITH conditions, add the following string after the issuer attribute

  • checkConditionTime="true" clockSkewMins="5" audience="https://xxxxxxxx/" />

4b. The resulting string should appear as in this example

  • issuer="http://host.example.com/trust" checkConditionTime="true" clockSkewMins="5" audience=" xxxxxxxx/" />
 For Identity Providers that are sending SAML WITHOUT conditions, click here

4a. For Identity Providers that are sending SAML WITHOUT conditions, add the following string after the issuer attribute

  • validityPeriodHours="1" clockSkewMins="5" />

4b. The resulting string should appear as in this example

  • issuer="http://host.example.com/trust" validityPeriodHours="1" clockSkewMins="5" />

5. These steps can be repeated for each issuer in the web.config file

6. Values for each parameter can be modified based on requirements in the environment, as explained below

checkConditionTime="True"

  • This condition checks if the SAML response is received by the Consumer provider between the times NotBefore and NotOnOrAfter (adjusted by clockSkewMins below)

clockSkewMins

  • To accommodate time differences in providers, clockSkewMins is used to offset and expand the allowed time frame that the SAML assertion is valid before it should be considered expired – the window of time is expanded both earlier and later by this value

  • clockSkewMins must be set (in minutes) along with checkConditionTime="True", even if not needed (set the value to "0")

audience

  • Enables a condition check for a matching Audience element in the SAML response – this condition check passes if the attribute value matches with the value of Audience element in the SAML response

validityPeriodHours

This attribute enables a condition check for the IssueInstant attribute in the SAML response and is used by Identity Providers that are sending SAML WITHOUT conditions

    • This condition check passes if the SAML response is received by the Consumer provider between the times IssueInstant and the number of hours elapsed from IssueInstant specified by validityPeriodHours

    • Value is in hours

    • clockSkewMins must be set (in minutes) along with ValidityPeriodHours

Logic for Condition Checking

The logic to allow or deny the SAML assertion for any of the available conditions is as follows:

  • A condition can be checked if and only if it is present in both the Service Provider's web.config and the Identity Provider's SAML Response.
  • If both values are present, then perform the condition check to determine whether to Allow or Deny the SAML assertion.
  • If one or both values are NOT present, then:
      1. If the SP is configured to check for that condition, then Deny the SAML assertion.
      2. If the SP is NOT configured to check for that condition, then Allow the SAML assertion.
Is SP Configured
to Check? 

Does IdP's SAML Response
Contain Condition?

Is Condition Met?ALLOW or DENY Assertion
YESYESYESALLOW
YESYESNODENY
YESNON/ADENY
NOYESN/AALLOW
NONON/AALLOW