Documentation

Introduction

Use this guide to configure the Workflow tab in the Web Admin for each SecureAuth IdP realm.

This includes Device Recognition (token and certificate properties), Workflow options (authentication modes, realm redirects, etc.), and consumption options (custom tokens, social identities, etc.).

Prerequisites

1. Create a New Realm for the target resource to which the configuration settings apply, or open an existing realm for which configurations have already been started

2. Configure the Overview and the Data tabs in the Web Admin before configuring the Workflow tab

Device Recognition
Device Recognition Method

1. Select the Integration Method from the dropdown

The selection made here alters the options for Client Side Control and IE / PFX / Java Cert Type

  • Select Certification Enrollment and Validation for web-based authentication (used most frequently for majority of application integrations)
  • Select Certificate Enrollment Only for X.509 VPN authentication
  • Select Mobile Enrollment and Validation for mobile browser authentication or enrollment (e.g. native mobile apps, OATH enrollment)

2. Select the Client Side Control option from the dropdown

The selection made here alters the options for IE / PFX / Java Cert Type, and may require additional configuration steps

Certification Enrollment and Validation Client Side Control Options
  • Select Java Applet to stores the SecureAuth IdP X.509 certificate in the JRE managed code file set
  • Select Browser Plug-ins to store the certificate in the native key store
  • Select Device / Browser Fingerprinting to enable SecureAuth Device Recognition mode, which pulls unique characteristics from the device or browser and stores them as a profile in the user directory rather than storing a cookie or certificate on the client

The Universal Browser Credential (UBC) has been deprecated for IdP versions 9.0+, but is still supported for earlier product versions

Certificate Enrollment Only Client Side Control Options

The Client Side Control is set to Browser Plug-ins / Keygen (no other option)

Mobile Enrollment and Validation Client Side Control Options
  • Select Browser Credential to store a cookie in the browser
  • Select Device / Browser Fingerprinting to enable SecureAuth Device Recognition mode, which pulls unique characteristics from the device or browser and stores them as a profile in the user directory rather than storing a cookie or certificate on the client

The Universal Browser Credential (UBC) has been deprecated for IdP versions 9.0+, but is still supported for earlier product versions

3. Select the IE / PFX / Java Cert Type from the dropdown

This is based on the security preference

Step 3 is not required if Device / Browser Fingerprinting is selected in step 2

Certificate / Token Properties

4. Select Password Expiration Date from the Certificate Expiration dropdown if the certificate is to expire when the password expires

Select Private Mode Cert Length if the certificate is to expire after a designated number of days

5. Select Cert Expiration Date from the Certificate Valid Until if the certificate is to remain valid up until the expiration

Select Private Mode Cert Length if the certificate is to remain valid during a designated number of days

6. Set the number of days during which a certificate does not expire and remains valid in the Private Mode Cert Length field if Private Mode Cert Length was selected in step 4 or 5

7. Set the number of hours during which the Public Mode Certificate is valid in the Public Mode Cert Length field

This is only for realms in which Certificate Enrollment is selected from the Integration Mode dropdown in the Device Recognition Method section

8. Set the number of hours during which the cookie delivered to a mobile device is valid in the Mobile Credential Length field (browser credential)

9. Provide a maximum amount of certificates that a user can have at a time in the Global Cert Limit field (optional)

10. Provide a maximum amount of mobile cookies that a user can have at a time in the Global Mobile Limit field (optional)

11. Select Fall Back to 2nd Factor or Display Error Message from the Check CRL dropdown for SecureAuth IdP to check the Certificate Revocation List

Select Disabled to opt out of checking the CRL as it is not necessary with SecureAuth IdP

12. Click Configure Email Notification to enable and set up Expired Certificate Warning emails (optional)

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

Expired Certificate Warning
Configuration Steps

 

1. Select Enabled from the Email Notification dropdown to enable the warning notifications

2. Select True from the Multiple Certs per User dropdown to notify users of all certificate expirations, rather than just one

3. Select the Email Property that corresponds to the data store field that contains the user's email address to which the notifications are sent from the Email Field dropdown

4. Set the number of days before the expiration on which the notifications begin in the Warning Period field

5. Select Daily from the Notification Interval dropdown for an email notification to be sent once a day

6. Set the Notification Start Time, at which the email is sent

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

Browser / Mobile Profiles

The following configuration steps are only required if Device / Browser Fingerprinting is selected in step 2 as the Client Side Control option

 

13. Configure the Device Recognition settings for the realm

Refer to Device Recognition for full configuration steps

Workflow
Workflow

Login Screen Options

14. Select the Default Workflow, which is the workflow through which users go to obtain access to the realm's resource

 Username only

User provides username only (no password or second factor required)

This option is usually selected only for specific configurations, such as Windows Desktop SSO

 Username | Second Factor

User provides username on one page, and then undergoes 2-Factor Authentication on subsequent page

This options requires configuration and enablement of at least one registration method in the Multi-Factor Methods tab

 (Valid Persistent Token) only

User presents a valid persistent token in lieu of a username only (no password of second factor required)

This option requires a different realm in which the Client Side Control token/certificate/fingerprint is generated to use in this realm

 Username & Password

User provides username and password on one page (no second factor)

 Username & Password | Second Factor

User provides username and password on page, and then undergoes 2-Factor Authentication on subsequent page

This options requires configuration and enablement of at least one registration method in the Multi-Factor Methods tab

 Username | Password

User provides username on one page, and then provides password on subsequent page (no second factor)

 Username | Second Factor | Password

User provides username on one page, undergoes 2-Factor Authentication on next page, and then provides password on subsequent page (standard workflow, recommended by SecureAuth)

This options requires configuration and enablement of at least one registration method in the Multi-Factor Methods tab

 (Valid Persistent Token) | Password

User presents a valid persistent token in lieu of a username on one page, and then provides password on subsequent page (no second factor)

This option requires a different realm in which the Client Side Control token/certificate/fingerprint is generated to use in this realm

 (Valid Persistent Token) | Second Factor

User presents a valid persistent token in lieu of a username on one page, and then undergoes 2-Factor Authentication on subsequent page

This option requires a different realm in which the Client Side Control token/certificate/fingerprint is generated to use in this realm, and configuration and enablement of at least one registration method in the Multi-Factor Methods tab

 (Valid Persistent Token) | Second Factor | Password

User presents a valid persistent token in lieu of a username on one page, undergoes 2-Factor Authentication on next page, and then provides password on subsequent page

This option requires a different realm in which the Client Side Control token/certificate/fingerprint is generated to use in this realm, and configuration and enablement of at least one registration method in the Multi-Factor Methods tab

15. Select Private and Public Mode from the Public/Private Mode dropdown to enable both modes during the login process

If the end-user selects Private Mode on the login page, then SecureAuth IdP checks for a certificate / token / device profile, or delivers a certificate / token to the browser or pull information to create a device / browser profile for subsequent access attempts

16. Select which option is selected by default (if Private and Public Mode is enabled) on the end-user login page from the Default Public / Private dropdown

17. Select True from the Remember User Selection dropdown if the user's last Private / Public Mode selection is defaulted for subsequent access attempts

18. Select False (default) from the Skip UserID View dropdown, which provides a username input field on the login pages

19. Select False (default) from the Show UserID Textbox dropdown, which provides a username input field on the login pages for Certificate Enrollment and / or Cisco ASA integrations when the user ID is not provided by Cisco

20. Select Enabled from the Inline Password Change dropdown to allow users to change their password during the workflow process

21. Configure the realm for Password Throttling (optional)

Session Timeout

These configuration steps are only required if session timeout occurs automatically after a set period of time

 

22. Set the Session State Name or leave it as the default value

23. Set the number of minutes after which the session is expired in the Idle Timeout Length field

24. Select the action to take after the session has been expired from the Display Timeout Message dropdown

Token Persistence

25. Select True from the Validate Persistent Token dropdown if SecureAuth IdP is to check the validity of the persistent token during the authentication process

Select False for this realm to only deliver certificates or create a profile, but not validate or renew the token

26. Select True from the Renew Persistent Token (After Validation) if the persistent token is to be renewed after SecureAuth IdP checks the validity (applicable only if True is selected in step 25)

Steps 25 - 26 apply to the Client Side Control option selected in step 2, i.e. the Device / Browser Profile, Native Cert, Java Cert, or UBC is the persistent token that can be validated and / or renewed through the workflow

Redirects

Redirects are optional and may not be relevant for every realm configuration

 

27. Set the Invalid Persistent Token Redirect field to where users are directed to acquire a new / valid persistent token, e.g. another SecureAuth IdP realm

This is especially useful in realms using (Valid Persistent Token) workflows as a valid token is required to access the resource

28. Set the Token Missing Redirect field to where users are directed to acquire a new token, e.g. enrollment or provisioning realm

This is used for Near Field Communications (NFC) tokens only

29. Set the Profile Missing Redirect field (or leave as default) to where users are directed to retrieve a missing profile, e.g. profilemissing.aspx

30. Set the If Mobile, Redirect To field to a SecureAuth IdP realm specifically configured for mobile access

31. Set the Mobile Identifiers to common keywords that can be used to detect mobile devices and browsers, which then triggers the mobile redirect to the realm selected in step 30

Termination Points

Termination Points are optional and may not be relevant for every realm configuration

 

32. Set the Client FQDN to the Fully Qualified Domain Name (FQDN) of the client point of termination for SecureAuth IdP validation

33. Provide the SSL Termination Cert if enabling bi-lateral authentication and if not using SecureAuth IdP as the termination point

34. If the SSL Termination Cert (step 33) cannot be provided, then set the (or) SSL Cert Address to the FQDN or IP Address of the (typically) Load Balancer at which the SSL connection is being terminated to enable SecureAuth IdP to retrieve the SSL certificate

35. Set the SSL Termination Point to the FQDN of where the SSL certificate is terminated, which is communicated to SecureAuth IdP to validate the information

Java

The following configuration steps are only required if Java Applet is selected in step 2 as the Client Side Control option

36. Select True from the Encrypt Password (Java only) dropdown to encrypt the end-user's password (provided during login) being sent to the SecureAuth IdP server for validation (rather than in plain text)

37. Set the Java Timeout to the number of X during which Java can respond

If no response during the configured time, then an error is presented

38. Select the action to take if SecureAuth IdP fails to launch the Java Applet from the Java Applet Load Failure Fallback dropdown

  • True - Public Mode: The user goes through an out-of-band one-time password
  • True - UBC: The Universal Browser Credential (UBC) is used instead
  • True - Cookie: A cookie is used instead
  • False: The user is denied access and is asked to contact Help Desk
Multiple Workflow Configuration
Configuration Steps

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

 

1. Click View and Configure Multiple Workflow only if this realm enables multiple data store integrations that lead to distinct workflows (optional)

Multiple Workflow Configuration

 

Refer to Multiple Workflow Configuration Guide for the configuration steps of this feature

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

Identity / Authentication Consumers
Custom Identity Consumer

Custom Identity Consumer configurations are optional and may not be relevant for every realm configuration

39. Select the type of token SecureAuth IdP receives in the realm from the Receive Token dropdown

40. Select True from the Require Begin Site dropdown if users are to acquire tokens / other information from a different site before logging in with SecureAuth IdP; or select False (default) if no begin site is required

41. Select the type of Begin Site from the dropdown that is used in this realm, which auto-populates the Begin Site URL field (unless Custom is selected)

Refer to the specific Begin Site Configuration Guide for full configuration steps

42. Select where the User ID is stored in the received token from the Token Data Type (Receive) dropdown

43. Select where the User ID is stored in the token sent to the SP from the Token Data Type (Send) dropdown

44. Select False from the Allow Transparent SSO dropdown

Select True if this realm utilizes SecureAuth IdP SSO, and enables SP-initiated or Secure Portal SSO

Also refer to the specific Integration Guide to view the distinct configuration steps

Open ID

Open ID configurations are only necessary if using Open ID in the realm

Configuration Steps

 

1. Provide the Open ID Provider URL in the Static OP Server URL field

2. Select the type of identifying claim that will be used in Open ID from the Federated OpenID dropdown

SAML Consumer

SAML Consumer configurations are only necessary if SecureAuth IdP is accepting a SAML assertion from one or multiple Identity Providers

Form Post

Form Post configurations are only necessary if SecureAuth IdP is accepting a Form Post

Configuration Steps

 

1. Select what user information is being sent for SecureAuth IdP validation in the Form Post from the Validation Mode dropdown

Social Identity

Social Identity configurations are only necessary if Social IDs are being consumed by SecureAuth IdP for use in multi-factor authentication

Configuration Steps

Facebook

1. Select True from the Enable dropdown to enable the use of Facebook ID for 2-Factor Authentication

2. Provide the Client ID, which is provided by Facebook

3. Provide the Client Secret, which is provided by Facebook

The Client ID and the Client Secret must match exactly here and on Facebook's side

4. Select where to Store Facebook ID at from the dropdown (e.g. Aux ID 1)

Google

5. Select True from the Enable dropdown to enable the use of Google ID for 2-Factor Authentication

6. Provide the Client ID, which is provided by Google

7. Provide the Client Secret, which is provided by Google

The Client ID and the Client Secret must match exactly here and on Google's side

8. Select where to Store Google ID at from the dropdown (e.g. Aux ID 2)

Windows Live

9. Select True from the Enable dropdown to enable the use of Windows Live ID for 2-Factor Authentication

10. Provide the Client ID, which is provided by Windows Live

11. Provide the Client Secret, which is provided by Windows Live

The Client ID and the Client Secret must match exactly here and on Windows Live's side

12. Select where to Store Windows Live ID at from the dropdown (e.g. Aux ID 3)

LinkedIn

13. Select True from the Enable dropdown to enable the use of LinkedIn ID for 2-Factor Authentication

14. Provide the Client ID, which is provided by LinkedIn

15. Provide the Client Secret, which is provided by LinkedIn

The Client ID and the Client Secret must match exactly here and on LinkedIn's side

16. Select where to Store LinkedIn ID at from the dropdown (e.g. Aux ID 4)

FBA WebService

FBA WebService configurations are only necessary if using SecureAuth IdP Web Service Multi-data Store, and if required by the SP

Configuration Steps

 

1. Select True from the Enable FBA WebService dropdown

2. Provide the FBA WebService UserName, which is the same as the Webservice Username in the Data tab

3. Provide the FBA WebService Password that corresponds to the username

iPhone / iPad Handling (Deprecated)

iPhone / iPad Handling configurations are only necessary if users utilizing an iPhone or iPad require redirection

This functionality has been deprecated. Previous deployments of the feature continue to be supported, but no new configurations are accepted.

Configuration Steps

 

1. Select the SecureAuth IdP realm to which iPhone / iPad users will be redirected from the Validation Realm dropdown

Consume Passcode from RADIUS 1.x Integrations

These configurations are only necessary if using SecureAuth RADIUS 1.0.x to make RADIUS web service calls to validate user information

Configuration Steps

 

1. Select what information is to be validated by SecureAuth IdP via the RADIUS web service call from the OTP Format dropdown