CLIENT IDENTIFICATION STRATEGIES AND POLICIES

OVERVIEW

Uniquely identifying a client is essential for device- and instance-based licensing. Depending on the application and deployment model, the licensed client may be a physical device, software installation, virtual machine, SaaS tenant, customer environment, or application instance.

Regardless of how the identifier is generated, the resulting value is normally sent to SLASCONE as the client_id.

The client_id should be sufficiently unique and remain stable for the expected lifetime of the licensed client. An identifier that changes unexpectedly may cause SLASCONE to treat the same installation or environment as a new client.

In general, there are three main identification strategies:

• Hardware ID

• Environment ID

• Random ID

In addition to choosing how the client_id is generated, SLASCONE provides a client identification policy that determines which values are used to distinguish one activated client from another.

CHOOSING AN ID STRATEGY

HARDWARE ID

To bind a license to a specific machine and reduce the risk of the same license being used across multiple devices, the application needs a sufficiently stable and unique device identifier.

This identifier can be based on one or more hardware-related values, such as:

• System UUID

• Processor ID

• Motherboard ID

• Operating system machine ID

• Physical or virtual MAC address

• Another application-specific identifier

As the software vendor, you decide which values best suit your application and how restrictive the device identification should be.

Hardware-related identifiers can usually be retrieved or derived whenever they are needed. If several values are combined or hashed, the algorithm must remain consistent across software versions so that the resulting client_id does not change unexpectedly.

There is always a trade-off between license protection and customer convenience. Combining several hardware values may make an identifier more difficult to copy, but it also increases the probability that the identifier changes after a hardware replacement or system modification.

ENVIRONMENT ID

In cloud, SaaS, hosted, virtualized, and platform-extension scenarios, relying on physical hardware identifiers is often not appropriate. The same applies when the licensed application is a plugin or extension running inside another platform.

In these scenarios, it is usually better to use a stable application- or environment-specific identifier, such as:

• SaaS tenant_id

• Environment or instance ID

• Platform installation ID

• Cloud subscription, resource, or virtual machine ID

• Another stable identifier managed by the application

For tenant-level SaaS licensing, the tenant identifier is normally used as the SLASCONE client_id. The tenant must be identified independently of the individual user currently accessing the application.

A customer number should only be used if it uniquely identifies the licensed environment. If one customer can have multiple tenants or environments, such as development and production, use a dedicated tenant, environment, or instance identifier instead.

Usernames and email addresses should normally only be used when the licensed unit is actually an individual user. They are generally not suitable identifiers for tenant- or environment-level licensing.

KNOWN CLIENT_ID DURING LICENSE CREATION

In many SaaS and automated provisioning scenarios, the client_id is already known when the license is created.

In this case, the edition can be configured to activate the license automatically during license creation. Creating the license is then sufficient, and no separate activation event from the application is required.

For details, see Activation upon creation options.

RANDOM ID

Another option is to generate a random identifier, such as a GUID, during installation or first application startup.

Unlike a hardware ID, the generated identifier must be stored by the application, for example in a local file, database, operating system configuration store, or another durable location.

The stored identifier should survive normal application restarts and updates. It should also be protected appropriately against accidental modification or deliberate manipulation.

You should define what happens after reinstallation, backup restoration, system cloning, or loss of the stored value. If the identifier is lost or regenerated, SLASCONE will normally treat the application as a new client.

PLATFORM NOTES

WINDOWS

On Windows, a system UUID can be retrieved through Windows Management Instrumentation using PowerShell:

(Get-CimInstance -ClassName Win32_ComputerSystemProduct).UUID

The returned value should be validated before it is used. Depending on the hardware, firmware, or virtualized environment, the UUID may be unavailable, invalid, duplicated, or represented by an all-zero value.

If the UUID cannot be retrieved reliably, use a clearly defined fallback strategy and ensure that the resulting client_id remains stable across application restarts and updates.

Avoid silently switching between unrelated identifier sources. If the preferred source temporarily fails and a different fallback value is used, the same machine may unexpectedly appear as a new client.

LINUX

On Linux systems, a commonly used machine-level identifier is:

/etc/machine-id

This file contains the local system's machine ID and is normally initialized during system installation or boot.

When distributing cloned virtual machine or system images, make sure that each deployed instance receives its own machine ID. Otherwise, multiple machines may generate the same client_id.

The application should also consider whether reinstalling or rebuilding the operating system is expected to preserve the same licensed identity.

AWS AND AZURE VIRTUAL MACHINES

If the software runs directly on an AWS EC2 or Azure virtual machine, it is usually preferable to use an identifier representing the cloud virtual machine itself:

• AWS EC2: Instance ID

• Azure Virtual Machines: VM ID

These identifiers can be retrieved through the cloud provider's instance metadata service.

Cloud VM identifiers are generally preferable to guest-level hardware values because they represent the virtual machine itself and help avoid ambiguous identifiers caused by image cloning.

Before choosing a cloud VM identifier, verify how it behaves when a virtual machine is restored, recreated, cloned, or migrated according to your infrastructure workflow.

DOCKER CONTAINERS

Docker containers are often recreated during deployments, updates, scaling, or recovery. A newly created container receives a new container ID.

For this reason, the Docker container ID or the default container hostname is normally unsuitable as a long-term client_id for a named license.

The correct identifier depends on what is being licensed:

• If the license belongs to a persistent application instance, generate or provide a stable identifier and store it in a persistent volume or external database.

• If the license belongs to a SaaS tenant, use the tenant identifier.

• If the license belongs to the underlying host or virtual machine, use the host or cloud VM identifier.

• Use the container ID only when each individual container is intentionally treated as a separate licensed client.

.NET AND NUGET PACKAGE

For .NET applications, the official SLASCONE NuGet package can retrieve device and environment information for Windows and Linux without requiring you to implement all platform-specific logic yourself.

Depending on the platform, the package can provide identifiers such as machine ID, host ID, MAC address information, and cloud environment details.

It can also help determine whether the application is running inside Docker, AWS, or Azure and retrieve the corresponding environment-specific information.

The application is still responsible for choosing which available value best represents the licensed client and for using that strategy consistently.

CLIENT IDENTIFICATION POLICY

The identification strategy determines how the application obtains the client_id. The client identification policy determines which values SLASCONE uses to decide whether two activations represent the same client.

SLASCONE supports two client identification policies:

• Based on client_id

• Based on client_id and token_key

The client identification policy is configured at the product level.

CLIENT_ID

With this policy, SLASCONE uses only the client_id to identify the activated client.

One client, instance, or installation can therefore be associated with only one active license for the product.

• Activating an already activated client_id with another license automatically deactivates the previous license assignment.

• Parallel installations of the same product using the same client_id, for example installations in different directories, cannot maintain separate active license assignments.

This is normally the appropriate policy when one physical device, SaaS tenant, environment, or application instance should correspond to one active license assignment.

CLIENT_ID AND TOKEN_KEY

With this policy, SLASCONE uses the combination of client_id and token_key to identify an activated client.

The same client, instance, or installation can therefore be associated with multiple active licenses, provided that each activation uses a different token_key.

• Parallel installations of the same product on the same device or instance can use separate licenses when each installation uses its own token_key.

• The same client_id can appear in several active license assignments because the complete identity also includes the token_key.

Use this policy only when the same client intentionally needs multiple parallel license assignments. For typical tenant-based SaaS licensing, where one tenant corresponds to one license assignment, the client_id policy is usually sufficient.

RECOMMENDED APPROACH

Choose the client_id based on the actual unit being licensed:

• Use a stable hardware or operating system identifier when licensing a physical machine.

• Use the cloud VM identifier when licensing a specific AWS or Azure virtual machine.

• Use a tenant, environment, or instance identifier for SaaS and hosted applications.

• Use a persistent random identifier when no suitable stable platform identifier exists.

Avoid choosing an identifier only because it is easy to retrieve. The identifier should represent the licensed unit, remain stable for its expected lifecycle, and behave predictably during updates, migrations, cloning, recovery, and reinstallation.