FLOATING USER LICENSES

The most common licensing provisioning mode is named, which means that for n users 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 user scenario, a license with n tokens allows n users to be active simultaneously. The n+1 user has to wait until a client disconnects in order to use the software.

Floating user licensing is typically found in:

• SaaS applications: there is only one application backend, receiving all incoming requests, which can originate from web, desktop or mobile clients. Only one physical installation communicates with SLASCONE. The user_id (username or email address) has to be unique across all end-customers. In such scenarios, the license is issued to a company/organization. This is by definition a B2B scenario.
• On Premise web applications: there are multiple physical installations (one per end-customer). The user_id (username or email address) has to be unique within an end-customer, but not necessarily across all end-customers. This is by definition a B2B scenario.
• Desktop applications: there are multiple physical installations (n per end-customer). The user_id (username or email address) has to be unique across all customers. This is by definition a B2B scenario.

CREATING A FLOATING USER 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: Users.
• Activation upon license creation: not set
• 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 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.

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

MAPPING A USER TO A LICENSE

In such scenarios, there is typically one license per customer (customer is a company). The challenge is to map a logged-in user to his/her respective company. The easiest way is to bind this to the domain of the email address. In any case this info should be saved as the legacy key. In the following screenshot, this license would only allow users with an email address ending with factor.com.

POST /api/v2/isv/{isv_id}/provisioning/licenses/by_license

ACTIVATION

OPEN SESSION

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

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

{
"license_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"client_id": "anna@factor.com",
"session_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"checkout_period": 0
}

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 USER

It is not unusual to have different sessions originating from the same user. This can be the result of a user opening multiple independent application sessions on the same client, or across clients.

The following property controls the maximum number of parallel sessions for a user (occupying 1 token).

CODE EXAMPLES

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