Tenant Configurations
Learn about the different features that can be customized for each tenant in Wristband.
Wristband provides granular configurations that can be overridden for any specific tenant in your application. If you're interested in learning how Wristband's hierarchical configuration model works, please see the Tenant Override System documentation. In the following sections, we'll list out all the tenant-level configurations that Wristband supports.
A Reminder About Application Inheritance
All of the tenant-level configurations described on this page can also be defined at the application level. If a tenant does not explicitly override a configuration, it will inherit the corresponding setting from its parent application.
Authentication Session Policies
When a user authenticates using Wristband, Wristband will create an authentication session for that user. If the user is redirected to Wristband's login page while still having an active authentication session, they will be immediately authenticated without needing to re-enter their credentials.
For each tenant, the authentication session idle and absolute expiration times can be configured. Likewise, the authentication session cookie can be configured to be persistent or not.
Email Branding
For specific authentication flows, Wristband will send transactional emails to your customers. For example, if a user forgets their password, Wristband will send them a password reset email. Using Wristband's email branding configurations, each tenant can modify various visual elements of their emails, including the logo, button color, and sender domain.
Email Policies
In addition to configuring the look and feel of transactional emails, you can also configure policies for any actionable links included within the email content. There are two things you can configure related to action links: the expiration time and the destination URL. Each email template can have its own email policy configured. For example, you could have the password reset link expire after 15 minutes, while the user invite link might expire after 7 days.
Identity Providers
Each tenant can be configured with their own unique set of identity providers. When users navigate to a tenant's login page, they can only authenticate using the identity providers enabled for that specific tenant. This feature is crucial for B2B use cases, where tenants will likely want to utilize their own internally managed enterprise identity provider to authenticate their employees.
Consider the following scenario: You've developed an application with three tenants: Tenant A, Tenant B, and Tenant C. Two of the tenants, Tenant A and Tenant B, are larger organizations that want to use their enterprise identity providers for single sign-on (SSO). While the third tenant, Tenant C, wants to use Wristband as their identity provider. In this case, you could configure Wristband as the default identity provider at the application level and then use tenant overrides to allow Tenant A and Tenant B to use their enterprise identity providers for authentication.
Figure 1. Illustration showing two tenants (Tenant A and Tenant B) with custom identity providers enabled and one tenant (Tenant C) inheriting its IdP configurations from the application.
Multi-Factor Authentication (MFA)
MFA policies control whether multi-factor authentication is required for users in a given tenant. When MFA is required, users must enroll in a second factor and complete an additional challenge at login. MFA policies can also be used to define which authentication factors users are allowed to enroll in, such as TOTP and recovery codes.
Page Branding
Wristband supports full customization of the look and feel of its hosted pages, such as login and signup, on a per-tenant basis. For B2B use cases, this enables you to white-label the authentication experience to match each customer's brand, including custom logos, color schemes, and background images. Offering white-labeled authentication pages can be a competitive advantage, since it makes your application more attractive to companies that want to provide a branded experience to their users.
Figure 2. Example of a custom-branded tenant login page.
Password Policies
Password policies are a set of rules and requirements that dictate how users must create and manage their passwords. Each tenant can have a different set of password policies to match each customer's security requirements. Password policies include the following:
| Configuration | Description |
|---|---|
| Minimum Length | The minimum number of total characters that a password is allowed to be. The minimum possible length is 8 characters. |
| Lowercase Characters | Determines if passwords should contain at least one lowercase character (a-z). |
| Uppercase Characters | Determines if passwords should contain at least one uppercase character (A-Z). |
| Numbers | Determines if passwords should contain at least one numeric digit (0-9). |
| Special Characters | Determines if passwords should contain at least one special character (!, @, #, $, %, &, etc.) |
| Password Breach Detection | Determines if Wristband should check passwords during creation or login to see if they have been compromised in a data breach. |
| Breach Password Login Remediation Strategy | If password breach detection is enabled and a breached password is detected during login, this configuration determines the action taken to remediate the breached password. |
Role Assignment Policies
Using Wristband's role assignment policies, tenants can specify rules regarding which roles should be assigned to users. Currently, the following rules can be configured:
- Default Signup Roles: The roles specified will automatically be assigned to users when they complete the self-signup flow.
- Default IdP User Sync Roles: The roles specified will be assigned to a user when the user is synced from an external IdP. For example, during enterprise SSO JIT provisioning flows. Note, the default roles defined here will only be used if no other role assignments are specified that have higher precedence.
User Schema
The user schema defines the structure and constraints of user fields. By modifying the user schema, you can change whether specific user fields are required or not. Wristband will automatically adjust the behavior of its authentication flows to accommodate any user schema changes. For example, if the given name field is marked as required, then Wristband will update the signup and invitation flows to prompt the user to enter their given name. Below is a list of user schema fields whose optionality can be configured:
- birthdate
- familyName
- fullName
- givenName
- phoneNumber
- username
Workflow Policies
Wristband supports per-tenant configuration of authentication workflows, allowing you to tailor the auth experience to each customer’s needs. For example, imagine a tenant where a large batch of users was imported without passwords. To ensure a smooth onboarding experience, the tenant admin can set the missing password remediation strategy in the Login Workflow Policy to REQUIRE_PASSWORD_RESET. With this configuration in place, any user attempting to log in to that tenant without a password will be automatically redirected to the password reset flow.
Below is a list of authentication workflows that can be configured at the tenant level:
- Signup
- Login
- Enterprise External IDP Login (SSO)
- Password Reset
- New User Invitation
- Existing User Invitation
Updated 1 day ago