Java Hardware _Device_ IDs

Introduction

LicenseSpring SDK already provides some preconfigured identity providers, which are described in the section below. If none of the preconfigured Identity providers match desired use case, feel free to make your own implementation of IdentityProvider interface which generates a custom HardwareId.

Getting Started

You can find all preconfigured Identity Providers in module LicenseSpring Core, package

com.licensespring.model as Enum HardwareIdStrategy.

Types of Identity Providers

Algorithms 7-12 are provided by the externally loaded LicenseSpring Hardware ID Generator library added in SDK v2.25.0. See Hardware ID generation for their descriptions.

1

AUTO_HARDWARE_ID

This identity provider will generate unique Identity key per device. That means that each device you are using will have its own unique identity.

Identity key is generated based on following 3 hardware components:

• Motherboard

• Processor (CPU)

• Hard disks or similar storage units

Use this strategy if you want to generate one and only one unique ID per device and you are running LicenseSpring on physical computer as opposed to running LicenseSpring on Virtual Machine.

2

NO_DISK_HARDWARE_ID

This identity provider is the same as AUTO_HARDWARE_ID, but without disk information. This is useful in cases where users add removable storage devices (like smart card reader) and the hardware ID changes.

3

AWS_NODE_LOCK

This identity provider will generate unique ID per Virtual machine running on AWS cloud platform. It will generate unique ID by using Virtual machine ID that is unique for each Virtual machine instance. In order to use this strategy, device which is running LicenseSpring must have Internet access as well as access to IP address 169.254.169.254. This is necessary because in order to retrieve VM ID, Metadata service API running on 169.254.169.254 must be called.

Use this strategy if you are running LicenseSpring on AWS cloud platform and want to generate one and only one unique ID per VM instance.

If using this identity provider you must be sure that LicenseSpring application will be running on AWS cloud platform. This is necessary because in case you are trying to use this identity provider on physical computer then NotCloudPlatformException will be thrown. Also, in case you are trying to use this on Virtual machine that is not running on AWS, WrongPlatformException will be thrown. Unless you are absolutely certain that LicenseSpring will be running on AWS, this strategy should be replaced with AUTO_NODE_LOCK.

4

AZURE_NODE_LOCK

This identity provider will generate unique ID per Virtual machine running on Azure cloud platform. It will generate unique ID by using Virtual machine ID that is unique for each Virtual machine instance. In order to use this strategy, device which is running LicenseSpring must have Internet access as well as access to IP address 169.254.169.254. This is necessary because in order to retrieve VM ID, Metadata service API running on 169.254.169.254 must be called. It also checks for the WEBSITE_INSTANCE_ID environment variable from version 2.4.7 (from version 2.5.2 in AUTO_NODE_LOCK too).

Use this strategy if you are running LicenseSpring on Azure cloud platform and want to generate one and only one unique ID per VM instance.

If using this identity provider you must be sure that LicenseSpring application will be running on Azure cloud platform. This is necessary because in case you are trying to use this identity provider on physical computer then NotCloudPlatformException will be thrown. Also, in case you are trying to use this on Virtual machine that is not running on Azure, WrongPlatformException will be thrown. Unless you are absolutely certain that LicenseSpring will be running on Azure, this strategy should be replaced with AUTO_NODE_LOCK.

5

AUTO_NODE_LOCK

This identity provider will attempt to figure out on which type of device you are running LicenseSpring (physical computer or virtual machine). If you are running on physical device then AUTO_HARDWARE_ID strategy will be chosen. If you are running on virtual machine then, depending on which cloud platform you are running LIcenseSpring, either AWS_NODE_LOCK or AZURE_NODE_LOCK strategy will be chosen.

Use this strategy if you are not sure on what type of device LicenseSpring will be running.

AUTO_NODE_LOCK strategy will not throw Exceptions like AWS_NODE_LOCK or AZURE_NODE_LOCK do. But because AUTO_NODE_LOCK needs to figure out which strategy to choose, it takes longer to execute.

6

ONCE_PER_PROCESS

This identity provider will generate new identity each time method getKey() is called. This is useful for generating multiple identity keys on one device. This strategy is useful for floating license as identity key is not bound to single hardware/device - so that multiple processes/VMs (or several layers of VMs) will have unique keys - preventing over-usage.

This is the default method used by the Floating Client module. See Java Modules. Use this strategy to control how many instances of your application are running. It also requires cacheHardwareID(boolean) to be true or a ConfigurationException will be thrown during init.

7

DEFAULT

8

WINDOWS_HARDWARE_FINGERPRINT_ID

9

WINDOWS_COMPUTER_SYSTEM_PRODUCT_ID

10

WINDOWS_CRYPTOGRAPHY_ID

11

LINUX_MACHINE_ID

12

CLOUD_PLATFORMS_ID

13

Custom identity provider

If none of identity providers matches your use case, feel free to make your own custom implementation. IdentityProvider interface can be implemented in the following way:

MyCustomIdentityProvider.java

public class MyCustomIdentityProvider implements IdentityProvider {
    @Override
    public String getKey() {
        return "myCustomIdentityKey";
    }
}