TENANT-BASED SaaS LICENSES – Help Center | SLASCONE

This article explains how to implement tenant-level licensing for B2B SaaS applications with SLASCONE.

In this scenario, the licensed unit is not an individual user or a physical device. Instead, the licensed unit is a SaaS tenant, customer environment, or application instance.

ASSUMPTIONS

This article assumes the following setup:

Each customer has a unique SaaS tenant, environment, or instance.
Entitlements are managed at the tenant level, not at the individual user level.
User management, user roles, and application permissions are managed in the SaaS application, not in SLASCONE.

Although such applications could be treated like traditional web applications, a simpler workflow is usually possible because the SaaS backend can integrate directly with SLASCONE during tenant onboarding and runtime checks.

LICENSING MODEL

For tenant-level SaaS licensing, the recommended SLASCONE model is usually a Named Device / Instance license.

In this context, the “device” or “instance” is not a physical machine. It is the SaaS tenant, customer environment, or application instance identified by a stable tenant_id.

This allows SLASCONE to manage entitlements for each tenant while the SaaS application remains responsible for authenticating users and enforcing user-level permissions internally.

TENANT IDENTIFICATION

The most important integration decision is the definition of the tenant_id. This value is used as the SLASCONE client_id and must uniquely identify the licensed SaaS tenant or instance.

SaaS applications typically use an identity provider such as Microsoft Entra External ID, Okta, Auth0, or a custom identity system. After authentication, the application maps the authenticated user to a tenant, for example based on the user account, domain, URL, organization, or internal tenant mapping.

The exact mapping logic is application-specific. For the SLASCONE integration, the important requirement is that the application can reliably determine a stable and unique tenant_id for every tenant.

Avoid using values that may not be unique enough, such as a customer number, if the same customer can have multiple environments, tenants, or instances. In such cases, use a dedicated tenant, environment, or instance identifier.

TENANT ONBOARDING WORKFLOW

Creating the SLASCONE license should usually be part of the SaaS tenant onboarding workflow.

When your SaaS application creates a new tenant or customer environment, the same workflow should also create the corresponding SLASCONE license using the tenant's tenant_id as the client_id.

This creates a direct relationship between the SaaS tenant and the SLASCONE license from the beginning of the tenant lifecycle.

CREATING A NAMED DEVICE / INSTANCE EDITION

The required licensing behavior is configured on the edition, not on the product. This allows you to offer different licensing models for the same product if needed.

For tenant-level SaaS licensing, create an edition with the following core properties:

Provisioning Mode: Named
Client Type: Devices
Activation upon license creation: enabled, using the tenant identifier as the activated client_id. For more guidance, see Activation upon creation options.

With this setup, each tenant or instance is represented as one named client in SLASCONE.

CLIENT/API CONSIDERATIONS

LICENSE CREATION AND ACTIVATION

In this scenario, license creation and activation are usually performed by the SaaS backend, not by an end-user desktop client.

Since activation upon license creation is enabled at the edition level, creating the license is sufficient. No separate activation event from the SaaS backend is required.

When a new tenant is created, the SaaS backend should create the corresponding SLASCONE license using the tenant's tenant_id as the activated client_id. This is important for two reasons:

It ensures that there is only one active license assignment for the respective tenant or instance.
Typical SLASCONE operations such as heartbeats, analytics, and session management are based on an activated client.

POST /isv/{isv_id}/licenses

RUNTIME ENTITLEMENT CHECKS

During runtime, the SaaS backend should use the tenant's license information to decide which features, limits, or modules are available for that tenant.

The application remains responsible for user authentication and user-level authorization. SLASCONE provides the tenant-level entitlements that the application can evaluate internally.

HEARTBEAT

After the license has been created and automatically activated, the SaaS backend communicates with SLASCONE to refresh the license and entitlement data for the tenant.

The heartbeat can be triggered periodically, for example every 24 hours, or by application events, such as when a user logs in and the backend needs to refresh the tenant's entitlement state.

In multi-user SaaS environments, the heartbeat should usually be handled at the tenant level, not for every individual user. If the heartbeat is triggered during user login, the backend should typically check when the last heartbeat was performed and avoid unnecessary repeated calls for the same tenant.

POST /isv/{isv_id}/provisioning/heartbeats

The heartbeat response contains the current license information and entitlement values. The SaaS backend can use this information to update its local entitlement cache.

Beyond licensing, the heartbeat can also provide usage-relevant technical information, such as software version or operating system, which can be used in the SLASCONE analytics area.

With this setup, SLASCONE manages tenant-level entitlements while the SaaS application remains responsible for user authentication, user roles, and application-specific permission checks.