Uniquely identifying an installation is obviously crucial in terms of device based licensing. There are three ways to uniquely identify an (on-premise) installation.
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:
- 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.
The simplest way to generate a unique device ID on Windows is to use the “wmic” command:
wmic csproduct get UUID
On Linux installations, the convention is to read
If your application runs in .NET Core, the official SLASCONE NuGet package returns a unique device id for both Windows and Linux, without you having to implement it.
Particularly for Linux environments, the NuGet package provides rich functionality, such as providing multiple hardware ids (e.g., machine ID, host ID, MAC ID) and functions helping you to identify a docker environment.
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.
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:
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).