FLOATING LICENSES

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.

SLASCONE provides a very flexible floating license functionality.

DEFINING AN EDITION’S PROVISIONING MODE

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: Named or floating. The provisioning mode of an edition can not be changed after its creation.
• Client Type: Devices or users. The client type of an edition can not be changed after its creation.
• 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 web applications in which users frequently close the browser without explicitly logging off, such session close events are not sent, resulting to 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.

MONITORING

In floating license models, it is always interesting to monitor the actual usage, in order to know if more (or even less) floating tokens are required. In this context, each time a client is unable to access the software application because all floating tokens are assigned, this is logged and visualized:

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

CLIENT/API CONSIDERATIONS

CLIENT ID

In floating scenarios, almost all relevant functions are based on a unique client_id.

DEVICE CLIENTS

If the clients competing for tokens/sessions are devices, then a unique device id has to be used as client_id.

USER CLIENTS

If the clients competing for tokens/sessions are users, then a unique user id has to be used as client_id, typically the email address.

In order to prevent username/email address sharing between multiple persons, which would obviously constitute a violation in the context of floating licensing, the client_id should additionally include some suffix uniquely identifying the originating client e.g., matthew@slascone.com___GAHGUKHJHDKJ.

In some cases, you might want to allow the same user to occupy only one floating token, regardless of the originating client (device_id). This is a typical case when simultaneously logged in through a pc and a smartphone. This can be achieved through the following edition property.

A value of 2 indicates, that the user matthew@slascone.com occupies one floating token if he is using simultaneously 2 devices. A 3rd device is going to be denied. For this to work, use the following client_id convention: <user_id>___<device_id>.

ACTIVATION

Similar to the named provisioning mode, the first step for a floating client is to get activated. Activation takes place once. After initial activation, SLASCONE’s session management of floating takes place.

Contrary to the named provisioning mode, a floating license code can be used to activate as many devices/users as possible. In other words, the number of floating tokens has no activation implications.

DEVICE CLIENTS

If the clients competing for tokens/sessions are devices, then the activation typically takes place when the user enters the license key, as described here.

USER CLIENTS

If the clients competing for tokens/sessions are users, then it can be safely assumed that the to be licensed application has a login (authentication) component. After a successful login, this component should check if the client (user) is already activated, and activate it if necessary. The advantage of this approach is that the activation process using a license key is performed in the background. The end-users do not have to enter any license key. 

OPEN SESSION

When starting the software application, your software sends an open session event:

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

The API returns one of the following:

• Successful: A floating token has been assigned. The response body also includes the floating token validity (valid until).
• Conflict 1007: The number of allowed connections has been reached. In this case, a session can not be initiated.

EXTEND SESSION

The client needs to regularly send open session events in order to keep the session alive. There are two ways that these can be achieved:

• Static: The session period is hard-coded in the application. In this case you have to make sure that the same session period is configured in the license template.
• Dynamic (recommended): In this case, the session period is not hard-coded in the software application, but depends on the timestamp returned by the first successful open session event. In this way, you have the flexibility to control  (and change if necessary) the session period in your license without having to change your code.

CHECKOUT SESSION

SLASCONE enables a session checkout in order to facilitate (partially) offline scenarios, e.g., when a device is on a construction site for some days, with no connectivity. 

The request body of the open session event contains an optional checkout_period field (in minutes). This value overrides the default session_period value of the license edition.

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

For example, if the open session event contains a checkout_period of 24x60=1440 minutes, the session is valid for 24 hours. During these 24 hours, no extend session event is necessary.

A check in occurs automatically after 24 hours, or if the client sends an explicit close session event.

CLOSE SESSION

As previously mentioned, it is important to explicitly close the session in order to unnecessarily reserve floating tokens, and prevent other clients from accessing the software application.

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

HANDLING MULTIPLE SESSIONS FROM THE SAME DEVICE

It is not unusual to have different sessions originating from the same client/device. This can be the result of a user opening multiple independent application sessions on the same device, or different users opening sessions within a server environment.

For such scenarios, you need to provide a session_id when opening and closing the session. This ensures that each session uses a different floating token.

CODE EXAMPLES

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