Authentication sub-step

Use the Authentication sub-step to protect an app by requiring the user to enter a passphrase, PIN, or biometric recognition before accessing the app. You can also configure options to require re-authentication after a period of user inactivity or when the user switches between different apps and returns to the original app. Additionally, this sub-step provides the ability for the client application to forward the provided OAuth Token, SiteMinder Token or x509 user certificate to a downstream server.

Stage	App Enhancement
Step	Blue Cedar Enforce

Using this sub-step in a workflow

In the workflow builder for your app:

Add the App Enhancement stage
Add the Blue Cedar Enforce step to the workflow.
Add the Authentication sub-step to the Enforce step.

Click on the options gear icon next to Authentication in the workflow outline. Configure the options:

Authentication

The configuration settings for Authentication are organized in two sections, shown in the App Enhancement / Blue Cedar Enforce / Authentication section of the workflow builder as these tabs:

Passphrase/PIN
Server Authentication

Passphrase/PIN

Option	Description
Security Method	Required (one of these): Use a passphrase (default) Use a PIN (at least 6 digits) Optional: Allow biometric authentication. If selected, the user can authenticate with fingerprint or Face ID (as available on the device).
Passphrase Requirements
Minimum Length	Required. The minimum number of characters required for a user passphrase or PIN (as selected above). Longer passphrases and PINs are more secure, but require more effort from the user.
Complexity	Optional. If selected, the user must select a complex passphrase or PIN. Complex passphrases may not contain four or more of each of the following: Same number and/or character, for example: 111111, abbbbc, 8888xyz Numbers and/or characters in sequence (including reverse), for example: 123456, 8765ab, abcde1928 Any sequence of numbers (including reverse) with the same interval, such as odd/even numbers, for example: 1357xxx, 8642000, 036999
Passphrase character types	(Passphrase only.) Passphrase must contain at least one of each selected character type: Alpha [a-zA-Z] Lowercase alpha [a-z] Uppercase alpha [A-Z] Numeric [0-9] Special (#, &, ~, etc.)
Options
History	Remember the last n passphrases/PINs Optional. If selected, the user cannot repeat a previously used passphrase when setting a new one
Invalid Passphrase/PIN handling	Lock user out of the app if user makes n consecutive incorrect passphrase/PIN entries Enable/disable lockout and select the number of attempts before locking the user out. If this option is enabled, and the app is not integrated with Blue Cedar Connect, the user is locked out after the specified number of invalid attempts. If this option is enabled, and the app is integrated with Blue Cedar Connect using a Blue Cedar or IKEv2 gateway, the user is locked out after the specified number of invalid attempts and the app allows the user to re-authenticate with their gateway enrollment credentials. The user can then set a new local app passcode.
Maximum Age Rule	User must change passphrase/PIN frequency Optional. Select whether the user must change the passphrase at a regular interval. You can set a reminder for the user as well.
Re-authentication	Optional. Select whether the user must enter their local passphrase or PIN in the selected case(s): When switching between apps When the app is idle for the configured number of minutes On Android, there is a 3-second grace period when switching apps before re-authentication is required.
Allow background access	Allow background access (bypass local authentication when app is launched by the system in the background) If selected, allow app launched in the background to access information secured by local app authentication. User interactions with the app still require local app authentication. For example, an app may not require the main UI to be available for certain tasks, such as an email client fetching emails and sending notifications for new email. This option allows the app's background processing to perform without having to ask the user to enter local app authentication credentials. Once the user is ready to interact with the app, the app prompts for local app authentication as usual. iOS: If allow background access is enabled, background tasks do not run (the user does not receive notifications) until the user has started the app manually. Android: If allow background access is enabled, background tasks including notifications work even before the user launches the app and authenticates.

Server Authentication

This option provides the ability for the client application to forward the provided OAuth Token, SiteMinder Token or x509 user certificate to a downstream server for use in authenticating the end user.

Option Description

Authentication Type

Required (one of these):

None (default)
OpenID/Authentication - provide the base url for the Server and client ID
- Enter the OpenID Base Discovery URL for the web authentication server.
  
  For example, if the OpenID metadata is published at the well-known URI such as oauth.example.com/.well-known/openid-configuration , the base discovery URL required for the field is oauth.example.com or oauth.example.com:1234 if a specific port is required.
- Enter the Client ID - the public identifier for this app.
- Pass token to URLs (Rule-Based Authentication)
  - Add URLs to this list to use OAuth authentication for app requests to those URLs. For example, if the app requests a URL within the bluecedar.com domain and https://*.bluecedar.com/* is on the list, the OAuth token obtained when the app was initially authenticated is passed to that URL for authentication.
    If the app requests a URL that isn't on this list, there is no effect—the app attempts to connect to the URL as usual.
    Format: You can use hostnames or IP addresses. Standard wildcard/glob matching applies.
  - Each URL Matching Rule can include a host pattern and a port. The asterisk wildcard (*) is accepted.
    - In the host part of the url, you can specify * for part of the hostname. For example, *.acme.com matches www.acme.com or email.acme.com, but not acme.com; *acme.com matches acme.com as well as www.acme.com and email.acme.com.
    - Enter the port as part of the hostname in the url, for example hostname → <hostname>:[port]. If you leave port empty, it defaults to port 443 (HTTPS). Use *443 to match 443, 8443, and so on.
- Enable Additional Scopes to authenticate and add them to the list to authenticate with specific scopes during OAuth. For information on OpenID Scopes please refer to: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Retrieve Credential from Blue Cedar Connect Gateway
- With User Certificate which allows the integrated app to enroll for a client certificate and use it to authenticate against the Blue Cedar Connect Gateway.
- With SiteMinder Token to allow the app to receive Single Sign-On credentials from the gateway during a VPN connection.
- Enable Pass certificate to hostnames
  - Enable only for the domains listed following the URL Matching Rule format. Each hostname matching rule rule can include a host pattern and a port. The asterisk wildcard (*) is accepted.
    - In the host pattern field, you can specify * for part of the hostname. For example, *.acme.com matches www.acme.com or email.acme.com, but not acme.com; *acme.com matches acme.com as well as www.acme.com and email.acme.com.
    - Enter the port as part of the hostname, for example hostname → <hostname>:[port]. If you leave port empty, it defaults to port 443 (HTTPS). Use *443 to match 443, 8443, and so on.