CLIENT IDENTIFICATION IN SLASCONE

OVERVIEW

Uniquely identifying an installation is crucial for device-based licensing. In practice, there are several ways to generate a unique client identifier, and the right approach depends on your application type and deployment model.

In general, there are three main approaches:

• Hardware ID
• Environment ID
• Random ID

In addition, SLASCONE supports different client identification policies that determine how the client identifier is used in licensing workflows.

CHOOSING AN ID STRATEGY

HARDWARE ID

To adequately protect your system and ensure that a license is not used on multiple machines, your software usually needs to generate a unique device ID. This is typically based on one or more hardware-related identifiers, such as:

• UUID
• Processor ID
• Motherboard ID
• Machine ID
• (Virtual) MAC Address
• Other custom ID

As a vendor, you decide what best suits your application and how restrictive the identification should be. In this model, the identifier is typically not stored permanently in the application, but generated each time it is needed.

There is always a trade-off between security and customer convenience. Combining multiple identifiers, such as MAC address and processor ID, increases protection, but also increases the probability that the generated ID changes after a hardware modification.

ENVIRONMENT ID

With the proliferation of cloud and virtualized systems, relying on a hardware ID is not always feasible. The same applies if your application is a plugin or an extension of another platform.

In such cases, it is often better to use an environment-specific identifier, such as a subscription ID, customer ID, username, email address, or another stable environment-level value.

RANDOM ID

Another option is to generate a random ID during installation. Unlike a hardware ID, this identifier must be stored locally by the application, for example in a file or a database.

If this approach is used, the stored value should be protected appropriately, for example through encryption or another mechanism that makes manipulation more difficult.

PLATFORM NOTES

WINDOWS

On Windows, one of the simplest ways to generate a unique device ID is to use the following command:

wmic csproduct get UUID

TROUBLESHOOTING MISSING UUID

If the UUID cannot be retrieved, this is often caused by a corrupt Windows Management Instrumentation (WMI), which is a standard component of Windows.

A corrupt WMI may cause an exception. In many cases, it is better to repair WMI instead of silently falling back to another identifier, because once WMI is repaired, for example by a Windows update, the generated client_id may change unexpectedly.

If such an abrupt identifier change is not critical for your workflow, for example in certain floating scenarios, a fallback strategy may still be acceptable. For desktop applications, it can also make sense to validate or even require a valid UUID during installation.

LINUX

On Linux installations, the standard convention is to read:

/etc/machine-id

This file contains the local system’s unique machine ID and is normally set during installation or boot.

AWS & AZURE VIRTUAL MACHINES

If your software runs on an AWS or Azure virtual machine, it is usually safer to use an identifier representing the virtual machine itself:

• AWS: Instance ID
• Azure: VM ID

This is strongly recommended because it helps avoid problems caused by VM cloning.

DOCKER CONTAINER

In Docker, each container has a unique identifier called the container ID. Normally, a truncated container ID is used as the hostname inside the container.

You can retrieve it, for example, through:

cat /etc/hostname

If the hostname has been overridden during container creation with the --hostname option, the container ID can also be extracted from files such as /proc/self/mountinfo.

.NET / NUGET PACKAGE

If your application runs on .NET Core, the official SLASCONE NuGet package can return a unique device ID for both Windows and Linux without requiring you to implement that logic yourself.

In Linux environments in particular, the package provides additional functionality, such as returning multiple hardware IDs, for example machine ID, host ID, or MAC ID, and helping identify whether the application is running inside Docker.

The same package can also detect whether the application is running in AWS or Azure and return the corresponding environment-specific identifier.

CLIENT IDENTIFICATION POLICY

In the context of the SLASCONE API, there are two client identification policies:

• Based on client_id (default)
• Based on client_id and token_key

Client identification policy is a product property.

CLIENT ID

Using only the client_id means that one client, instance, or installation can be associated with only one license.

• Activating an already activated client, instance, or installation with a new license automatically deactivates the previous license.
• Parallel installations of the same product on the same client or instance, for example in different directories, are not possible, because activating one would automatically deactivate the other.

CLIENT ID AND TOKEN KEY

Combining client_id and token_key means that one client, instance, or installation can be associated with multiple licenses.

• Parallel installations of the same product on the same client or instance, for example in different directories, are possible, because each installation uses its own token_key.