Customizing Tenants

In Wristband, you can override the configurations for a specific tenant within an application. This means that any tenant can be modified differently from the default configuration settings of the application to meet their own requirements. The customization of one tenant does not affect any other tenant in the application. In this way, overriding the configurations for a specific tenant allows for greater customization and flexibility within a multi-tenant application, enabling each tenant to tailor the application to their specific requirements.

Ownership and Overrides

In order to support isolated tenant configurations, Wristband has a system of ownership and overrides. Let's take the identity provider configurations for an application as an example. The application owns a set of identity provider configurations that determine how users log in to the application. By default, when application users land on the login page, they will see the identity provider and login options assigned from the application level.

Tenants also own their own set of identity provider configurations. By default, the identity provider values match that of the application configurations. Each tenant can alter those values of the identity providers solely for themselves. However, changing the values is not enough for users under that tenant to see the new login options on the login page. The tenant override flag must also be enabled. Enabling the override tells Wristband to use the tenant configurations instead of the application configurations. That override flag can be turned on or off at any time.

All App-level Configurations Model

For the case where no tenant within an application has been customized, all tenants inherit their configurations from the application level.

All App-level Configurations Model

Mixed Configurations Model

In the case where some tenants have overrides enabled, those who do not have overrides enabled will inherit their configurations from the application level.

Mixed Configurations Model

All Tenant-level Configurations Model

It is also possible to override configurations for every single tenant such that the default application level configurations are never utilized.

All Tenant-level Configurations Model

Possible Tenant Configurations

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.

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.

Email Branding

Any email branding configuration changes will be applied to all email templates that Wristband supports. This includes the following email templates:

WorkflowEmail Templates
SignupUser Activation
Email VerificationEmail Verification
LoginMagic Link Login
Tenant DiscoveryTenant Discovery
Forgot PasswordPassword Reset, Password Updated
Change EmailEmail Change Confirmation, Email Change Completed, Email Change Notification, Passwordless Email Change Confirmation: Current Email
Invite New UserEmail-only User Invitation
Invite Existing UserExisting 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.

Email Policies

Wristband supports the following configurations for email action link duration time:

Min Duration Until Expired

The 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.

WorkflowEmail Templates with Action LinksMax Duration Until Expired
SignupUser Activation7 days
Email VerificationEmail Verification7 days
LoginMagic Link Login20 minutes
Tenant DiscoveryTenant Selection1 day
Forgot PasswordPassword Reset1 day
Change EmailEmail Change Confirmation, Passwordless Email Change Confirmation: Current Email1 day (applies to both templates)
Invite New UserEmail-only User Invitation7 days
Invite Existing UserExisting User Invitation7 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.

Identity Providers

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 Branding

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

Page Branding

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:

ConfigurationDescription
Minimum LengthThe 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 CharactersDetermines if passwords should contain at least one lowercase character (a-z).
Uppercase CharactersDetermines if passwords should contain at least one uppercase character (A-Z).
NumbersDetermines if passwords should contain at least one numeric digit (0-9).
Special CharactersDetermines if passwords should contain at least one special character (!, @, #, $, %, &, etc.)
Password Breach DetectionDetermines if Wristband should check passwords during creation or login to see if they have been compromised in a data breach.
Breach Password Login Remediation StrategyIf 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:

FieldHow To Enforce Requirement
birthdateConfigurable by End User
emailAlways Required
externalIdRequired 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
fullNameConfigurable by End User
givenName (first name)Configurable by End User
phoneNumberConfigurable by End User
usernameRequired 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.

User Schema

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