website logo
⌘K
Getting Started
Introduction
Basic Concepts
Opening an Account
Creating & Configuring Products
Integrating SDK and Configuring License Fulfillment
Activate a Key-Based License
Vendor Platform
Issuing New Licenses
License Detail View
Order Detail View
Customer Detail View
Metadata
Analytics
Settings
Product Configuration
Product Features
Product Custom Fields
Product Versioning
License Policies
Product Bundles
License Entitlements
License Types
Activations & Device Transfers
Features
Custom Fields
License Start Date
License Note
Maintenance Period
Trial Licenses
Floating Licenses
License Activation Types
Portals
End-User Portal
Offline Portal
Air-Gapped Portal
License API
License API Authorization
License Activation/Deactivation
License Check
Consumption
Floating
Trial Key
Product Details
Device Variables
Changing Password
Management API
Making API Requests
Management API Authorization
Customer
Product
Order
License
Device
Analytics
SDKs
Tutorials
.NET/C# SDK
.NET/C# Management SDK
C++ SDK
Java SDK
Python SDK
Go SDK
Delphi SDK
Swift/Objective-C SDK
Android SDK
Unity SDK
Errors and Response Codes
Floating Server
API Reference
Deployment
Configuration
Floating Server UI
Securing the Server
Whitelabeling
FAQ
Floating Server Changelog
Integrations
Salesforce
FastSpring
Stripe
Shopify
Common Scenarios
Single Sign On (SSO)
Glossary
General
SDK Glossary
Vendor Platform
Product Configuration Glossary
License Configuration
Postman Collections
Frequently Asked Questions
Changelog
License API changelog
Platform changelog
Docs powered by
Archbee
SDKs
Java SDK

Java Hardware (Device) IDs

13min

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

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:

  1. Motherboard
  2. Processor (CPU)
  3. 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 in in the 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 SDK. Use this strategy in order to completely control how many instances of your application are running.

7. 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:

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




Updated 15 Sep 2023
Did this page help you?
PREVIOUS
Management SDK
NEXT
Javadoc & Downloads
Docs powered by
Archbee
TABLE OF CONTENTS
Introduction
Getting Started
Types of Identity providers
1. AUTO_HARDWARE_ID
2. NO_DISK_HARDWARE_ID
3. AWS_NODE_LOCK
4. AZURE_NODE_LOCK
5. AUTO_NODE_LOCK
6. ONCE_PER_PROCESS
7. Custom identity provider
Docs powered by
Archbee