Documentation

Table of Contents


Other Resources


The Workflow tab is configured on a SecureAuth IdP realm to provide the way in which end-users will access a realm. A workflow might include use of any of the following options:



What's new in SecureAuth IdP version 9.3

Two new fields – Use Kernel Mode and Use AppPool Credentials – added in the Custom Identity Consumer section can now enable kernel mode authentication and application pool credentials (Active Directory service account) in environments using custom Service Principal Names for Integrated Windows Authentication (Kerberos). In prior versions of SecureAuth IdP, these entries were made in the web.config editor.

Workflow guides from the previous release

See the collection of Workflow configuration guides under this category:

 


Prerequisites

On the New Experience user interface in version 9.3, you can configure an Active Directory integration or SQL Server integration to be applied to applications made from App onboarding library templates. Configure the remaining components – for example, Workflow, Multi-Factor Methods, and Adaptive Authentication tabs – on the Classic Experience user interface.



SecureAuth IdP Web Admin - Classic Experience

Device Recognition 

Device Recognition Method section

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
  • Java Applet stores the SecureAuth IdP X.509 certificate in the JRE managed code file set.
  • Browser Plug-ins stores the certificate in the native key store.
  • Device / Browser Fingerprinting enables SecureAuth Device Recognition mode. This mode pulls unique characteristics from the device or browser and stores these 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
  • Browser Credential stores a cookie in the browser.
  • Device / Browser Fingerprinting enables SecureAuth Device Recognition mode. This mode pulls unique characteristics from the device or browser and stores these 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 selection is based on the security preference.

NOTE: This step is not required if Device / Browser Fingerprinting is selected in step 2.

Certificate / Token Properties section

4. Select Password Expiration Date from the Certificate Expiration dropdown for the certificate to expire on the same day the password expires.

Select Private Mode Cert Length for the certificate to expire after a designated number of days.

5. Select Cert Expiration Date from the Certificate Valid Until dropdown for the certificate to remain valid up until the expiration date.

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

6. If Private Mode Cert Length was selected in step 4 or 5, make an entry in the Private Mode Cert Length field to set the number of days a certificate will remain valid and will not expire. 

7. If Certificate Enrollment was selected from the Integration Mode dropdown in the Device Recognition Method section, make an entry in the Public Mode Cert Length field to set the number of hours during which the Public Mode Certificate is valid.

8. Make an entry in the Mobile Credential Length field (browser credential) to set the number of hours a cookie delivered to a mobile device remains valid.

9. OPTIONAL: Make an entry in the Global Cert Limit field to set the maximum number of certificates a user can have at a time.

10. OPTIONAL: Make an entry in the Global Mobile Limit field to set the maximum number of mobile cookies a user can have at a time.

11. OPTIONAL: To have SecureAuth IdP check the Certificate Revocation List, select Fall Back to 2nd Factor or Display Error Message from the Check CRL dropdown.

Select Disabled to opt out of checking the CRL.

12. OPTIONAL: Click Configure Email Notification to enable and set up Expired Certificate Warning emails.

13. Save the configuration.

Expired Certificate Warning

Configure Email Notification

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. Make a selection from the Email Field dropdown to select the Email Property corresponding to the data store field containing the user's email address for receiving notifications.

4. Make an entry in the Warning Period field to set the number of days before the expiration date on which notifications will be sent.

5. Select Daily from the Notification Interval dropdown to send an email notification once per day.

6. Set the Notification Start Time for sending email notifications.

7. Save the configuration.

Browser / Mobile Profiles section

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

14. Configure Device Recognition settings for the realm.


Workflow 

Workflow section

Login Screen Options

15. Select the Default Workflow, which is the workflow for users to access 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 two-factor authentication on a subsequent page.

This options requires configuration and enablement of at least one registration method on 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 for use on 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 the page, and then undergoes two-factor authentication on a subsequent page.

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

 Username | Password

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

 Username | Second Factor | Password

User provides username on one page, undergoes two-factor authentication on next page, and then provides password on a subsequent page (standard workflow, recommended by SecureAuth).

This options requires configuration and enablement of at least one registration method on 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 a subsequent page (no second factor).

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

 (Valid Persistent Token) | Second Factor

User presents a valid persistent token in lieu of a username on one page, and then undergoes two-factor authentication on a subsequent page.

This option requires a different realm in which the Client Side Control token/certificate/fingerprint is generated for use on this realm, and configuration and enablement of at least one registration method is made on 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 two-factor authentication on next page, and then provides password on a subsequent page.

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

16. 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.

17. If Private and Public Mode is enabled, make a selection from the Default Public / Private dropdown for the option that appears by default on the end-user login page. 

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

19. Select False (default) from the Skip UserID View dropdown if the username input field should not appear on login pages.

20. Select False (default) from the Show UserID Textbox dropdown if the username input field should not appear on the login pages for Certificate Enrollment and / or Cisco ASA integrations when the user ID is not provided by Cisco.

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

22. OPTIONAL: Configure the realm for Password Throttling.

Session Timeout

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

23. Set the Session State Name or leave the default value.

24. Set the number of minutes in the Idle Timeout Length field to the length of time until the session expires.

25. Make a selection from the Display Timeout Message dropdown to specify the action after the session expires.

IMPORTANT: To prevent time synchronization errors in the SecureAuth0 realm, set the Idle Timeout Length to the same value as the Timeout Minute(s) configured on the Forms Authentication section of the Post Authentication tab.

 Timeout configuration example on Post Authentication tab...

Access the Forms Authentication section from the View and Configure FormsAuth keys / SSO token link in the Forms Auth / SSO Token section on the Post Authentication tab.

Token Persistence

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

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

Select False if this realm will only deliver certificates or create a profile, but not validate or renew the token.

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

Redirects

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

28. Set the Invalid Persistent Token Redirect field so that users are directed to acquire a new / valid persistent token – example: 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.

29. Set the Token Missing Redirect field so that users are directed to acquire a new token – example: enrollment or provisioning realm.

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

30. Set the Profile Missing Redirect field (or leave as default) so that users are directed to retrieve a missing profile – example: profilemissing.aspx

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

32. Set the Mobile Identifiers to common keywords that can be used to detect mobile devices and browsers, which trigger the mobile redirect to the realm specified in step 31.

Termination Points

33. Set the Client FQDN to the Fully Qualified Domain Name (FQDN) of the client termination point used by SecureAuth IdP to validate the information.

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

35. If the SSL Termination Cert (step 34) can't be provided, then set the (or) SSL Cert Address to the FQDN or IP Address of the (typically) Load Balancer to which the SSL connection is being terminated, enabling SecureAuth IdP to retrieve the SSL certificate.

36. Set the SSL Termination Point to the FQDN of the site where the SSL certificate is terminated – this 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.

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

38. Set the Java Timeout to the set amount of time in which Java can respond.

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

39. Make a selection from the Java Applet Load Failure Fallback dropdown to specify what happens if SecureAuth IdP fails to launch the Java Applet:

  • 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 the Help Desk.

Multiple Workflow Configuration section

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

OPTIONAL: Multiple workflow configuration settings

Multiple Workflow Configuration sub-section

1. Refer to Multiple Workflow Configuration Guide for this feature's configuration steps.

2. Save the configuration.



Identity / Authentication Consumers

Custom Identity Consumer section 

The Custom Identity Consumer configuration is optional and may not be relevant for every realm configuration.

40. Make a selection from the Receive Token dropdown to specify the type of token SecureAuth IdP can receive on the realm being configured.

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

42. Make a selection for the type of Begin Site used on this realm – this information auto-populates the Begin Site URL field (unless Custom is selected).

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

See Windows desktop SSO configuration for the latest configuration guide for this begin site.

43. Make a selection from the Token Data Type (Receive) dropdown to specify where the User ID is stored in the token SecureAuth IdP receives. 

44. Make a selection from the Token Data Type (Send) dropdown to specify where the User ID is stored in the token sent to the SP. 

45. Select False from the Allow Transparent SSO dropdown.

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

NOTE: Also refer to the specific Integration Guide to view the distinct configuration steps.

Save the configuration on the Workflow tab after completing all necessary steps for the workflow.

Open ID section

An Open ID configuration is only necessary if using Open ID on the realm.

Open ID configuration

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

2. Make a selection from the Federated OpenID dropdown for the type of identifying claim to be used in Open ID.

SAML Consumer section

A SAML Consumer configuration is only necessary if SecureAuth IdP is accepting a SAML assertion from one or multiple Identity Providers.

Form Post section

A Form Post configuration is only necessary if SecureAuth IdP is accepting a Form Post.

Form Post configuration
1. Make a selection from the Validation Mode dropdown to specify the type of user information to be sent to SecureAuth IdP for Form Post validation.

Social Identity section 

A Social Identity configuration is only necessary if Social IDs are being consumed by SecureAuth IdP for use in two-factor authentication.

Social Identity configuration

Facebook

1. Select True from the Enable dropdown to enable the use of Facebook ID for two-factor authentication.

2. Set the Client ID which is provided by Facebook.

3. Set 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. Specify where to Store Facebook ID at from the dropdown (example: Aux ID 1)

Google

5. Select True from the Enable dropdown to enable the use of Google ID for two-factor authentication.

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

7. Set 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. Specify where to Store Google ID at from the dropdown (example: Aux ID 2).

Windows Live

9. Select True from the Enable dropdown to use Windows Live ID for two-factor authentication.

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

11. Set 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. Specify where to Store Windows Live ID at from the dropdown (example: Aux ID 3).

LinkedIn

13. Select True from the Enable dropdown to use LinkedIn ID for two-factor authentication.

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

15. Set 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. Specify where to Store LinkedIn ID at from the dropdown (example: Aux ID 4).

FBA WebService section

An FBA WebService configuration is only necessary if using SecureAuth IdP Web Service Multi-data Store, and if required by the SP.

FBA WebService configuration

1. Select True from the Enable FBA WebService dropdown.

2. Set the FBA WebService UserName, which is the same as the Webservice Username on the Data tab.

3. Set the FBA WebService Password which corresponds to the username.

iPhone / iPad Handling section (Deprecated)

An iPhone / iPad Handling configuration is only necessary if users with an iPhone or iPad require redirection.

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

iPhone / iPad configuration
1. Make a selection from the Validation Realm dropdown for the SecureAuth IdP realm to which iPhone / iPad users will be redirected.

Consume Passcode from RADIUS 1.x Integrations section

This type of configuration is only necessary if using SecureAuth RADIUS 1.0.x to make RADIUS web service calls to validate user information.

Consume Passcode from RADIUS 1.x configuration
1. Make a selection from the OTP Format dropdown for the type of information to be validated by SecureAuth IdP via the RADIUS web service call.