Documentation

Error rendering macro 'rw-search'

null

Table of Contents


Other Resources


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The Workflow tab is configured on a SecureAuth IdP realm to provide the way end-users access a realm. Workflows include use of Device Recognition (token and certificate properties), options such as authentication modes and URL redirection to other realms or pages, and consumer options such as custom tokens and social identities.



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

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

 

 

 

Device Recognition

 

 

Certificate / Token Properties

 

 

 

Expired Certificate Warning

 

 

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

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

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

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

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

User provides username and password on one page (no 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

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

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

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

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

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

  • No labels