Uniquely identifying an installation is obviously crucial in terms of device based licensing. There are three ways to uniquely identify an (on-premise) installation.

HARDWARE ID

In order to adequately protect your system (i.e., make sure a license key is not used on multiple machines), your software has to generate a unique device ID. This is usually a combination of:

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

As a vendor you (not SLASCONE) have to decide what suits more to your application, in other words how restrictive you want to be. In any case, this ID is not being saved in your application, but generated every time its value is needed.

It should be noted though, that there is a trade-off between security and customer convenience. Increasing the number of identifiers (e.g., MAC + Processor ID), increases the probability of a new unique identifier upon hardware change. 

WINDOWS

The simplest way to generate a unique device ID on Windows is to use the “wmic” command:

wmic csproduct get UUID

LINUX

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 some platform.

In such cases, there is usually a unique environment identifier you can refer to. This might be a subscription or a customer identifier, or even a username or email. Please refer to the respective documentation.

AWS & AZURE Virtual Machines

if your software runs on an AWS or Azure virtual machine, it is much safer to use an ID identifying the virtual machine.

• AWS: Instance ID
• Azure: VM ID

Using this is highly recommended since it prevents any potential issues arising from VM cloning.

If your application runs in .NET Core, the official SLASCONE NuGet package identifies if the application runs in AWS or Azure and returns the respective ID. The mechanism is the same for any operating system.

Docker container

In Docker, each container has a unique identifier called the container ID. This ID is automatically assigned when you create a container. If you want to retrieve the hostname of the Docker host from inside a container, you have a few options.
Normally a truncated container ID is set as hostname inside the container. You can access it with either the hostname command or via the /etc/hostname file.

cat /etc/hostname

In case the hostname is overwritten on container creation with the --hostname option you can extract the container ID e.g. from the /proc/self/mountinfo file.

RANDOM ID

An alternative option to a hardware ID, is to generate a random ID during the installation. Contrary to a hardware ID, this ID needs to be saved in your application (in a file or in a database), using some sort of encryption in order to avoid easy manipulation.

CLIENT IDENTIFICATION POLICY

Uniquely identifying an installation is obviously crucial in terms of device based licensing. in the context of the SLASCONE API, there are two different policies:

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

 Client identification policy is a product property:

CLIENT ID

Using the client_id implies that one client/instance/installation can only be associated with one license. Practically, this implies:

• Activating an already activated client/instance/installation with a new license, leads to deactivation of the initial license. This is done automatically.
• Parallel installations on a specific client/instance (e.g., in different directories) of the same product, are not possible (since activating one, would automatically deactivate the other one).

CLIENT ID AND TOKEN KEY

Adding the token_key to the client_id implies that one client/instance/installation can be associated with multiple licenses. Practically, this implies:

• Parallel installations on a specific client/instance (e.g., in different directories) of the same product, are possible (since each installation has its own token_key).