Tenant Configurations
Learn about the different features that can be configured uniquely for each tenant in Wristband.
There are several configurations that can be overridden for any specific tenant in your application. Configuration overrides can be enabled or disabled at any time, and changes are reflected immediately throughout Wristband.
Tenant-level overrides
You can change settings at both the
ApplicationandTenantlevel. In order to apply a specific change to a tenant remember to select "Enable this tenant override?" on the page.
Auth Session Policies
Wristband maintains an authentication (auth) session for any user who logs into your application, regardless of how they authenticated. Typically, the auth session expiration configurations would appease the security requirements for most tenants using your application. However, there may be specific customers that want tighter control over how quickly an authenticated user in Wristband is forced to reauthenticate again. This can be the case for security-conscious customers or those who need to adhere to certain compliance audits and regulations.
Refer to the Authentication Sessions section of the documentation to see which auth session configurations Wristband currently supports.
Email Branding
Tenants seeking a white-label experience within your application aim to align the visual elements of their transactional emails with their brand identity. This encompasses everything from the logo to the sender's email domain. These tenants can easily override the default email branding to achieve the look and feel they require.
Any email branding configuration changes will be applied to all email templates that Wristband supports. This includes the following email templates:
| Workflow | Email Templates |
|---|---|
| Signup | User Activation |
| Email Verification | Email Verification |
| Login | Magic Link Login |
| Tenant Discovery | Tenant Discovery |
| Forgot Password | Password Reset, Password Updated |
| Change Email | Email Change Confirmation, Email Change Completed, Email Change Notification, Passwordless Email Change Confirmation: Current Email |
| Invite New User | Email-only User Invitation |
| Invite Existing User | Existing User Invitation |
Email Policies
In addition to configuring the look and feel of transactional emails, you can also configure policies around any actionable links that users would click inside of the email content. There are two things you can configure related to action links: the duration of time the link is valid before it expires and the destination URL a user gets sent to when clicking the link.
Some customers may have stricter security requirements around how long email action links should be valid for their users. They may also want to have more control over customization by pointing the URLs to pages they host.
Wristband supports the following configurations for email action link duration time:
Min Duration Until ExpiredThe minimum allowable duration for configuring an email action link before it is deemed expired is 10 minutes. This is consistent across all email template types.
| Workflow | Email Templates with Action Links | Max Duration Until Expired |
|---|---|---|
| Signup | User Activation | 7 days |
| Email Verification | Email Verification | 7 days |
| Login | Magic Link Login | 20 minutes |
| Tenant Discovery | Tenant Selection | 1 day |
| Forgot Password | Password Reset | 1 day |
| Change Email | Email Change Confirmation, Passwordless Email Change Confirmation: Current Email | 1 day (applies to both templates) |
| Invite New User | Email-only User Invitation | 7 days |
| Invite Existing User | Existing User Invitation | 7 days |
Identity Providers
As depicted in the sections above, each of your tenants can define their unique set of identity providers for authenticating into the application. This is particularly essential when developing a SaaS product tailored for SMBs and enterprises. These organizations often demand Single Sign-On (SSO) integration to enable employees to log in using their company's employee directory services rather than passwords. With various customers having diverse authentication preferences, Wristband simplifies the configuration of each customer's preferred authentication method, ensuring a tailored approach for every user.
Consider this scenario: You've developed an application that serves both startups and enterprises. Startups find email/password login via Wristband sufficient. However, when dealing with large enterprise clients, the story changes. For instance, you have two enterprise customers who prefer using enterprise SSO for authentication. One wishes to leverage their internal Okta directory, while the other prefers their internal Microsoft directory for login.
Refer to the Identity Providers section of the documentation to see which identity providers and login factors Wristband currently supports.
Multi-factor Authentication (MFA)
MFA policies allow you to tailor security measures to the specific needs and risk profiles of each customer tenant. This includes whether MFA is required or optional as well as if recovery codes can be generated and used in the event a user's device has been lost. Wristband currently only supports TOTP-based MFA with authenticator apps. Support for additional MFA factors and policies are on the roadmap and continually being added.
Page Branding
Like Email Branding, you can configure the look and feel of each tenant's Wristband-hosted pages. This is required for any companies who want a white-label authentication experience to match their brand identity. White-label pages allow each tenant to maintain a consistent brand identity throughout the user experience. This includes incorporating their own logo, color scheme, and visual elements, which reinforces their brand and ensures a seamless transition from their website to the login page.
Scope of Page BrandingWhenever configuration changes are made to Page Branding, those changes take effect in every Wristband-hosted page. This includes public-facing pages like signup, login, etc. as well as any page that is reachable via an email action link (i.e. Reset Password page, Email Verification page, etc.).
When selling a SaaS solution to other businesses, offering white-label authentication pages can be a competitive advantage. It makes your service more attractive to companies that want to provide a branded experience to their users. It helps accommodate the diverse needs of different tenants and makes it easier to onboard and retain a variety of clients.
Password Policies
Password policies are a set of rules and requirements that dictate how users must create and manage their passwords. Wristband currently supports the ability to enforce certain character sets as well as detect if passwords have been leaked in a data breach. Each tenant can have a different set of password policies to match each customer's security and risk profile. Policies include the following:
| Configuration | Description |
|---|---|
| Minimum Length | The minimum amount of total characters that a password is allowed to be. The minimum possible length is 8 characters. Longer passwords are highly recommended. |
| 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 on login, this will determine if users be required to reset their password before they are allowed to log in again. |
Role Assignment Policies
Wristband supports the ability to define policies around when and how roles can be assigned to your application's users. Currently, we support the ability to automatically assign roles to users for the following cases:
- Whenever a user signs up for your application, they can automatically be assigned any default Wristband roles of your choosing.
- When a user logs in to your application via enterprise Single Sign-On (SSO) with Just In Time (JIT) Provisioning enabled, they can automatically be assigned any default Wristband roles of your choosing.
User Schema
In Wristband, a user schema is the set of fields associated with each User, such as username, email address, full name, etc. Wristband provides a way to enforce constraints or rules on certain fields in the User Schema. Currently, the only supported constraint you can configure is making some fields required during new user creation in Wristband. The following fields have have rules around being required:
| Field | How To Enforce Requirement |
|---|---|
| birthdate | Configurable by End User |
| Always Required | |
| externalId | Required for users provisioned in a non-Wristband (external) identity provider; optional for users provisioned in the Wristband identity provider |
| familyName (last name) | Configurable by End User |
| fullName | Configurable by End User |
| givenName (first name) | Configurable by End User |
| phoneNumber | Configurable by End User |
| username | Required for users provisioned in the Wristband identity provider AND username is chosen as a login factor; optional for all other scenarios |
This applies for the Create User API, the Signup API, and the New User Invite API.
It also applies to any Wristband-hosted pages where the aforementioned APIs are triggered. Let's say that Wristband made fullName a required field for any news users joining the platform. In the example below, the Wristband-hosted Signup page would now prompt the user to provide their full name while filling out the form. The same would be required on the Wristband-hosted New User Invite page as well.
Workflow Policies
Wristband offers the flexibility to configure specific aspects of authentication workflows independently for each tenant, catering to the dynamic preferences that different tenants may have for these workflows. To illustrate, some tenants may wish to set a custom redirect URL for the New User Invitation workflow. In this scenario, after the end user accepts the invitation on a Wristband-hosted page, the Wristband platform will redirect the user to a destination of their choice, rather than immediately accessing the application. The following workflows support some type of configurable policies:
Workflows with Policy Support
- Signup
- Tenant Discovery
- Login (Policies common across various types of login)
- Enterprise External IDP Login (SSO) (Policies specific to enterprise idP login)
- Forgot Password
- New User Invitation
- Existing User Invitation
Updated 20 days ago