Documentation

Introduction

SecureAuth IdP can act as a Service Provider (SP) to consume SAML assertions from one or multiple Identity Providers, and assert specific attributes from the Identity Provider to the target SP without requiring data store integration.

When a realm is configured to accept a SAML assertion from an Identity Provider, an SP Meta File can be generated to enable appropriate mapping from the Identity Provider data store to SecureAuth IdP Properties, which can then be asserted to the post-authentication event (e.g. application). This enables SecureAuth IdP to send its own Properties (Phone 1, Email 1, Aux ID 1, and more) that contain user information extracted from the enterprise directory integrated with the Identity Provider.

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

3. Know which attributes are required for the post-authentication target to appropriately map them to SecureAuth IdP Properties (SecureAuth IdP Meta File)

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 information

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

8. Click the arrow on the Edit button, and select Generate SP Meta File

Service Provider (SP) Metadata File

 

9. Set the Domain (FQDN) to the Fully Qualified Domain Name of the SecureAuth IdP appliance, e.g. https://secureauth.company.com, and click Generate SP Metadata File

10. Open the file to retrieve information regarding how attributes need to be sent to SecureAuth IdP in order to properly assert them to the post-authentication target

Take note of the AssertionConsumerService Location, which is where the Identity Provider posts the SAML assertion

 Example Image of Meta File

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

Post Authentication

 

11. In the Post Authentication section, select the post-authentication target (typically a SAML or WS-* integration) from the Authenticated User Redirect dropdown

User ID Mapping

 

12. Select Authenticated User ID (default) from the User ID Mapping dropdown; or the SecureAuth IdP Property that contains the user ID to be asserted to the SP (Email 1, Aux ID 1, etc.)

SAML Attributes / WS Federation

 

13. Set the Name of the attribute as required by the SP

14. Select the appropriately-mapped SecureAuth IdP Property from the Value dropdown

15. Fill out any other fields as required by the SP

16. Repeat steps 13-15 in the additional Attributes sections as needed to assert the required attributes to the SP

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

Forms Auth / SSO Token

 

17. Click View and Configure Forms Auth keys / SSO token

Forms Authentication

 

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

Authentication Cookies

 

19. Set the Post-Auth Cookie name to the same token name set in step 18

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