A Strivacity application is a collection of policies that define the sign-in, sign-up, and self-service journey for your brand’s protected resources. This page will show you how to configure mandatory settings, adjust default session management settings, and manage optional add-ons like consents, lifecycle event hooks, or login providers.

📘

You can choose from three types of applications depending on the complexity of your brand’s organizational needs. Mandatory settings and most of the optional settings are the same for each application type.

Mandatory settings

When creating a new application, some mandatory settings must be configured to save the application.

General tab

Name

The name of the application goes here. The application will appear by this name in the application listing.

Identity store

Applications need an identity store that will contain the customer and administrative identities signing up, invited, or created.

❗️

Identity stores for organization-enabled applications (organization-only and hybrid) can't be changed after being saved when creating the application.

Tag

You can add a tag to applications to help categorize and organize them for easier management and search.

Policies tab

You can set up policies for the application that define the functionality and appearance of customer experiences.

📘

A policy is simply a group of reusable common settings that can be assigned to an application. You can reuse the same policy by applying it to one or more applications.

Adaptive access policy

Defines the login workflow, access rules, and MFA requirements of the application.

Self-service policy

Defines in-line and account and self-service capabilities.

Branding policy

Allows you to add unique branding to customer experiences.

Notification policy

Defines notification content that is sent to customers.

Optional settings

You can manage optional settings that give you command over many aspects of the application. You can navigate to Applications in the Admin Console and select an application to access configurations.

Description

You can add a brief description of the application that appears in the Admin Console only.

Group restriction (within identity stores)

The purpose of group restriction is to provide customers access to the applications relevant only to them while multiple applications can use the same identity store. This information can also be included and passed to the brand portal via ID tokens, access tokens, or SAML2 assertions.

Identifier and session management

Identifier and session management settings allow you to define the parameters of your customers' login and account sessions.

Remember account identifiers after the session ends

This setting allows admins to control if a customer's identifier can be remembered for a device/browser and whether the customer has control over when an identifier is remembered. It has four settings:

• Always remember identifiers: The customer's identifier is always remembered when coming back to log in from the same device/browser
• User chooses to remember - checked by default: Customer gets the option to choose whether or not they want their identifier remembered in this device browser and is checked by default.
• User chooses to remember - un-checked by default: Customer gets the option to choose whether or not they want their identifier remembered in this device browser, and is un-checked by default.
• Never remember identifiers - The customer's identifier is not remembered and there is no setting for a customer to remember their identifier.

Allow users to remember their devices even if they choose to not remember identifiers

This setting determines if the "Remember this device" option is shown to the customer during the MFA step when the identifier is not remembered and the option is available based on the Adaptive access policy configuration.

Keep me logged in

“Keep me logged in” is a feature that allows customers to opt in or opt out of re-authentication when signing up for or logging into their accounts. Customers can return to a brand portal without having to provide a password until the specified inactivity timeout elapses.

This option for users is enabled by default. The "Keep me logged in” checkbox appears in the sign-up and sign-in journeys under the password field.

If customers don’t check “Keep me logged in”, they need to provide a password to access their profile if the access token or refresh token has expired.

Fastpath

Combined with device recognition, "Keep me logged in" can remove friction from the sign-in experience entirely for a single customer account in a browser. Fastpath skips account selection and simply forwards a user to the brand portal.

Fastpath is a result of the combination of these conditions:

• The user has checked “Keep me logged in” at a previous sign-in
• Only a single account is remembered in the browser’s session
• The user is signing in from a trusted device which means
  • they’ve opted in to “Remember my device” when completing an MFA step at a previous sign-in
  • their device is within the device recognition lifetime set in Adaptive rules
• The user's session is within the inactivity timeout (and the session max age if applied)

Customers can active Fastpath if they select “Keep me logged in” when

• Asked for their password
• At the bottom of their registration form
• While completing their invitation

Inactivity timeout

Inactivity timeout allows a customer to return to a brand portal without needing to present a password if they’ve checked “Keep me logged in” while signing in. The inactivity timeout is reset every time a customer returns to the brand portal and a new access token or refresh token is generated.

If a customer tries to return to the brand portal once the inactivity timeout is up, they will need to re-enter their password to access the application again.

Session max age

Session max age determines how long inactivity timeout is allowed to be reset when customers return to a brand portal. If the session reaches its total allowed lifetime, the customer needs to re-authenticate even if they were still within the latest inactivity timeout.

Session max age is activated by switching on “Let session expire”.

Login session max age

This setting determines how long you want to keep a login session alive once a customer starts their login or registration journey. If customers can't authenticate or register before the time is up, they'll receive a session expired message.

Default session configuration

The following session management configurations and parameters are applied to every application by default:

Consent management

Here, you can configure any Consent Management option for this Application. For further information on setting up Consent Statements see Creating a Consent (if you do not have any created yet) or Assigning a Consent to an Application.

Lifecycle event hooks

The Strivacity Lifecycle Event Hooks (LEH) provides a method to integrate your customer-facing applications with homegrown systems and third-party products.

Once you've created event hooks and tested the integration of the hook with your third-party enterprise applications, you can assign it and its functions to a customer-facing application.

This is the last step to realizing the actual functionality of your event hook for your application.

Policies

Identity verification policy

This policy allows you to confirm the identity of your online customers by applying document-centric and data-centric methods.

📘

Identity verification is an add-on capability that can be requested. Check with your Strivacity sales or customer success representative to add these features to your service.

Login providers

Here, you can configure how you want to provide the login experience for your application.

Local login

You can disable local login when you only want to use external login providers.

When local login is disabled:

• username or email address fields will not appear on the login screen
• the forgotten username option will not be available
• your customers will not see their remembered accounts

External login

Strivacity supports external identity providers that allow your customers to federate into applications using their existing enterprise or social identity.

📘

We support multiple social provider integrations.

You can find out more about how to set up your enterprise login for an application here.

Forward customers to an external provider

You can create a seamless experience if only one external provider is available for your application. If switched on, customers will land directly on the external provider’s authorization page at login.