FLOATING DEVICE LICENSES AND FLOATING LIMITATIONS

The most common licensing provisioning mode is named, which means that for n clients you would provision n tokens. However, the floating (also known as concurrent) licensing model is a viable model used by several software vendors. In a floating scenario, a license with n tokens allows n clients to be active simultaneously. The n+1 client has to wait until a client disconnects in order to use the software.

Floating device licensing is commonly used in desktop applications that do not communicate with a dedicated application backend.

CREATING A FLOATING DEVICE EDITION

The provisioning mode is an edition (not a product) property. This allows you to offer both named and floating licenses for a specific product. The following parameters are important when creating/editing an edition:

• Provisioning Mode: Floating.

• Client Type: Devices.

• Session Period: Ideally, clients send a session close (disconnect) event when access to the software application is not necessary anymore. This is mandatory in order to make sure that floating tokens become available again, ready to be assigned to other clients. However, especially in desktop applications in which users frequently do not explicitly close the application, such session close events are not sent, resulting in zombie sessions. In order to circumvent this, the session period defines the maximum inactivity period in minutes for a client. If SLASCONE does not receive any event during a session period, it automatically unassigns this token.

• Overusage: This lets you control if the floating token limit is soft or hard. Allowing overusage usually implies that the actual floating token is analyzed through SLASCONE out-of-the box session analytics.

LICENSE-LEVEL VS LIMITATION-LEVEL CONCURRENCY

Floating licensing can be applied at different levels.

The classic floating device model controls how many clients, devices, installations, or application instances may use a license at the same time. For example, a license with 10 floating tokens allows up to 10 parallel active instances of the application.

In addition to this license-level concurrency, SLASCONE can also enforce concurrency for specific limitations. This makes it possible to allow access to the application for a larger number of clients while restricting the parallel use of a specific capability.

To enable limitation-level floating, the limitation must be configured as a floating limitation at the edition level. Similar to license-level floating, each floating limitation has its own:

• Session Period: the maximum inactivity period after which the limitation-level session is released automatically.

• Overusage: defines whether the limitation-level concurrency limit is enforced as a hard or soft limit.

For example, a license may allow 10 parallel application instances, while a specific limitation may only be used by 4 clients or sessions at the same time. In this scenario, the 5th client may still be able to use the general application, but access to the restricted capability is denied until one of the active limitation-level sessions is released or expires.

License-level and limitation-level sessions can be used independently or together. For example, an application may open a license-level session when the application starts and open an additional limitation-level session only when the user starts using a restricted feature. When the feature is no longer used, the limitation-level session should be closed, while the general application session may remain active.

SESSION ANALYTICS

In floating license models, it is useful to monitor actual usage to understand whether more or fewer floating tokens are required.

PREVENTING OVERUSAGE (HARD LIMIT)

If overusage is not allowed, SLASCONE prevents access when all available floating tokens are already assigned. Each denied session is logged and can be analyzed.

In addition to the log, a chart helps you identify the number of denied sessions over time:

ALLOWING OVERUSAGE (SOFT LIMIT)

If overusage is allowed, SLASCONE does not block access when the configured floating limit is exceeded. Instead, the actual usage can be analyzed afterwards.

LICENSE LEVEL

At the license level, you can analyze:

• The number of total sessions
• The average duration of all sessions
• The maximum number of concurrent sessions, revealing peaks and potential overusage

PRODUCT LEVEL

At the product level, the Session Compliance Overview allows you to identify licenses with overusage during a specific time window.

CLIENT/API CONSIDERATIONS

ACTIVATION

Similar to named provisioning mode, the first step for a floating client is activation. Activation takes place once. After initial activation, SLASCONE's session management controls concurrent usage.

Activation typically takes place when the user enters the license key, as described here.

Unlike named device licensing, activation does not consume floating capacity. A floating license key can therefore be used to activate multiple devices, while the configured floating token limit is enforced when sessions are opened.

OPEN SESSION

When starting the software application, or when accessing a floating limitation, your software sends an open session event:

POST /isv/{isv_id}/provisioning/session/open

The request body can be used for both license-level and limitation-level floating:

{
  "license_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "client_id": "string",
  "session_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "limitation_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "checkout_period": 0
}

• Omit limitation_id for license-level floating.

• Include limitation_id when opening a session for a floating limitation.

• Use checkout_period only when a longer checked-out session is required.

The API returns one of the following:

• Successful: a floating token has been assigned. The response body also includes the floating token validity.

• Conflict 1007: the number of allowed connections has been reached. In this case, a session cannot be initiated.

EXTEND SESSION

The client needs to regularly send open session events to keep the session alive. There are two ways to achieve this:

• Static: the session period is hard-coded in the application. In this case, make sure that the same session period is configured in the edition or floating limitation.

• Dynamic, recommended: the session period is not hard-coded in the application, but calculated based on the validity timestamp returned by the first successful open session event. This gives you the flexibility to change the session period in SLASCONE without changing your code.

CHECKOUT SESSION

SLASCONE enables session checkout for partially offline scenarios, for example when a device has no connectivity for a defined period of time.

The request body of the open session event contains an optional checkout_period field in minutes. This value overrides the default session period of the edition or floating limitation.

For example, if the open session event contains a checkout_period of 24 * 60 = 1440 minutes, the session is valid for 24 hours. During these 24 hours, no additional open session event is required to keep the session alive.

Check-in occurs automatically after the checkout period expires, or earlier if the client sends an explicit close session event.

CLOSE SESSION

As previously mentioned, it is important to explicitly close the session to avoid unnecessarily reserving floating tokens and preventing other clients from using the software.

POST /isv/{isv_id}/provisioning/session/close

For limitation-level floating, close the corresponding limitation-level session by including the relevant limitation_id.

HANDLING MULTIPLE SESSIONS FROM THE SAME DEVICE

It is not unusual to have different sessions originating from the same client or device. This can happen when a user opens multiple independent application sessions on the same device, or when different users open sessions within a server environment.

• In such scenarios, provide a session_id when opening and closing the session. This ensures that each session uses a different floating token.

• If you do not provide a session_id, a client occupies only one floating token, regardless of the number of parallel sessions.

WHAT TO SAVE IN YOUR CLIENT

Please refer to this article.

CODE EXAMPLES

You can find code examples of floating licenses on our GitHub repository.