Application setup

1) Navigate to Applications in the Admin Console.

📘

You can find every existing application on the landing page.

2) Click "+ Create Application".

🚧

A blank template will open with several all-important and complimentary application configuration options.

Mandatory settings

Name in General settings

You can provide the name of the application here. The application will go by this name in the Admin Console e.g. in the application listing.

Application properties in General settings

In this section, you can set up policies in your application.

📘

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.

Strivacity has 8 major policy types with their own distinct set of capabilities of which 5 are essential for applications to work:

❗️

Identity stores

Identity stores for organization-only and hybrid applications cannot be changed after being saved when creating the application.

1. Identity store Contains the customer and administrative identities of the application.
2. Adaptive MFA policy Defines the login workflow of the application.
3. Self-service policy Defines the basic self-service capabilities of customer accounts.
4. Branding policy Adds your unique branding to customer experiences.
5. Notification policy Provides automatic communication with customers.

Dialect in OAuth2/OIDC

Here, you can specify the claim dialect that's used by the application. By default, the 'OpenID Connect' claim dialect is used.

Optional settings

The configurations listed here may be optional, but they give you command over many aspects of the application to shape it to your brand's needs.

Description

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

Application domain

Here, you can choose an alternative domain name for your application to set it apart from the rest of your applications. You'll find every domain name variation you can choose from in the drop-down.

🚧

It's best to decide on an alternative domain when creating the applications. Changing the application domain along the way will end customers' active sessions and remove remembered accounts.

Alternative domains contain a prefix or a suffix before or after your brand ID.

By default, applications use the Default domain name which is either <yourID>.strivacity.com or a vanity domain you’ve decided on when creating your instance.

✅

Get in touch with Strivacity's customer success team to extend the list of alternative domains available for your instance.

Application properties

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.

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.

Application URLs

Website URL

Allows you to add a web address to self-service accounts. Customers can access this page using the “Back to website” button.

Self-service URL

This part contains an auto-generated URL that navigates customers to the application's self-service portal where they can log in and register.

A fully constructed URL looks like this:

https://yourID.strivacity.com/myaccount/oauth2/authorization/CLIENT_ID

📘

Please see the API Documentation for more information on the parameters in these URLs.

Customer friendly self-service URL

This option creates a friendly self-service URL masking the part of the URL that doesn't mean much to your customers. The wording you enter here will be joined to your domain.

Customer friendly login page URL

Customers can bookmark the login page of your application for later.

By default, the login URL uses the first 7 characters of the Client ID from the self-service URL.

In this field, you can override the default characters with something more on-brand and meaningful for your customers.

Application launcher

The application launcher capability allows quick access for customers to their available applications from the convenience of their accounts.

Before application short-cuts can appear in a customer's account, the capability has to be enabled for the application.

You can activate the capability with the Enabled switch. This setting does two things at once:

• it allows the shortcuts of other applications to appear in the self-service portal
• at the same time, the current application also becomes a shortcut

Editing the shortcut

You can add a label to the current application's shortcut in the Display field.

You can add the logo of your shortcut in the Logo URL field.

📘

Supported formats: SVG and PNG.

Session management

Here, you can define the parameters of your application's user sessions.

Keep me logged in

You can let customers stay logged in to their accounts if they leave their session.

The "Keep me logged in" switch displays the option for customers on the password input screen. If they opt in, their MyAccount session will not be terminated if they close their browser.

The availability of this option is enabled by default.

"Keep me logged in" simplifies the login experience on devices where only a single session exists:

Fastpath

We’re all about building forgettable customer journeys, that's why we're introducing Fastpath.

If there’s only a single remembered account in a browser’s session, customers can leave and return without any friction on a trusted device.

To activate Fastpath, customers can select “Keep me logged in” when

• asked for their password
• at the bottom of their registration form
• while completing their invitation

Inactivity timeout

Here, you can determine how long a customer can stay inactive in their authenticated session until they're logged out and forced to re-authenticate.

The session inactivity timeout is set to 168 hours (7 days) by default.

Login session max age

Here, you can determine how long you want to keep a login session alive once a customer started their login journey. If customers can't authenticate until the time is up, they'll receive a session expired message.

The lifetime of the login session is set to 5 minutes by default.

Login providers

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

Interactive login

Switch off interactive login and registration when you want to use an application exclusively for machine-to-machine communication e.g. with APIs. This way customers won't be able to log in to 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 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.

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