This article explains the necessary steps in named-device scenarios. The term named-device should not be just associated with on-premise desktop or web applications. Instead it is intended for all scenarios require that each installation/device/instance is uniquely identified. Examples:
Desktop apps, without an identity provider and user authentication.
Single-Tenant B2B Web apps, either on-premise or deployed in whatever virtualized environment.
Multi-Tenant SaaS Apps (each tenant represents an instance).
CREATING A NAMED DEVICE/INSTANCE EDITION
Named device functionality is unleashed as an edition (not a product) property. This allows you to simultaneously offer both named and floating licenses for a specific product. The following parameters are important when creating/editing a named device edition:
Provisioning Mode: Named
Client Type: Devices
Activation upon license creation: not set
CLIENT/API CONSIDERATIONS
These are the fundamental functions you need to integrate in your software. You need to provide an area in your software in which the end user can:
enter the provided license code (ACTIVATION)
update/sync the license (HEARTBEAT)
Make sure that your environment has at least one license, in order to be able to test these functions.
LICENSE ACTIVATION
The licensing lifecycle begins with the activation of a device. In most cases, you need to provide an area in your software, in which the end user can enter the provided license code.
For example, this area in your software could look like this:
Upon entering the license code, your software should call this method:
POST /isv/{isv_id}/provisioning/activations
SLASCONE provides 2 types of license keys:
License key: when you create 1 license with n tokens, SLASCONE generates 1 license key and n token keys. The license key can be used n times for activation.
Token key: a token key can be used only once for activation.
The activation might fail for several reasons:
The license is not active (inactive or expired).
The license key is already activated on a different client (to prevent license piracy).
The license has not any available tokens left (all tokens are already assigned).
CLIENT REACTIVATION WITH A NEW LICENSE
In case you activate an already activated client with a new license, the old license becomes automatically available again.
HEARTBEAT
After activating a client, you need to make sure that your software periodically communicates with SLASCONE in order to sync the license data. More about the recommended heartbeat frequency can be found here.
POST /isv/{isv_id}/provisioning/heartbeatsThe response body of the heartbeat method is very similar to the one of the license activation.
Beyond licensing purposes, when calling the heartbeat method your software needs to send its software version and operating system. This data is used in the Analytics area of SLASCONE.
LICENSE UNASSIGNMENT (DEACTIVATION)
The licensing lifecycle for a device ends with its unassigment/deactivation. It is recommended to provide an area in your software, in which the end user can unassign the used license code, so that this can be used on another device (typical hardware migration scenario).
POST /isv/{isv_id}/provisioning/unassign
WHAT TO SAVE IN YOUR CLIENT
Please refer to this article.
NUMBER OF ALLOWED ACTIVATIONS (TOKENS)
SLASCONE supports two types of license keys:
License Key: When a license is created, SLASCONE generates one license key and n associated token keys. The license key can be used n times for activation.
Token Key: Each token key is single-use and can be used only once for activation.
If an end customer operates two installations, such as a development and a production environment, a license with 2 tokens is required. The customer can either use the license key twice (once per installation) or use each of the two token keys individually.
GOODWILL TOKENS
Consider a scenario such as a video or music streaming service where the vendor wants to limit account sharing by restricting access to 3 devices per user. SLASCONE enforces this limit by preventing a 4th device from activating.
To mitigate potential customer dissatisfaction from such a hard enforcement, SLASCONE introduces Goodwill Tokens. With this feature, the vendor can extend the allowed number of activations from 3 to 3 + 1 (Goodwill). Goodwill tokens represent a soft limit, creating a “yellow zone” where the client exceeds the licensed limit but can continue using the service temporarily.
SLASCONE provides analytics and monitoring of Goodwill token usage, enabling vendors to take appropriate actions—for example, issuing warnings after Goodwill activation or notifying affected customers via email.
Comments
0 comments
Please sign in to leave a comment.