NAMED USER LICENSES

Named user licensing is a common requirement, that 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.
  • B2B: in such scenarios, the license is issued to a company/organization. A license administrator manages (assigns/unassigns) licenses to the company's employees.
  • B2C: in such scenarios, the license is issued to a person. Therefore, this scenario is a less dynamic, and thus far less complex than the B2B case.
• 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.
• On Premise 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.

AUTHENTICATION AND IDENTITY PROVIDER

This article assumes that there is already an identity provider (IdP) in place, whether custom or a commercial solution such as Auth0, Active Directory (B2C), Okta, which handles the whole authentication process. After successful authentication, the application backend communicates with SLASCONE in order to fetch the user's entitlements.

Refer to this article if there is no identity provider in place.

CREATING A NAMED USER EDITION

Named user functionality is unleashed as 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 a named user edition:

• Provisioning Mode: Named
• Client Type: Users
• Activation upon license creation
  • For SaaS: token key or customer number
  • For on premise: not set

MANAGING USERS OF A NAMED USER LICENSE

Named user licenses allows you to create/edit/delete users. The list of users is part of the information returned by the SLASCONE API. In the following example, the license allows maximum 3 users. Although, you can add as many users as you want, only 3 can be active.

If you activate the License user groups option, you can create individual groups for each license and assign a user limit to each of these groups.

Although, you as a vendor can use the SLASCONE UI to manage the users, typically you would prefer to allow your end-customer to self-manage this information. This can be done:

• directly in your application (recommended in most cases): this implies that you need to implement user management functionality in your code. In this case, SLASCONE returns the number of allowed users. Your application is then responsible for adding/deleting users according to the limit returned by SLASCONE.
• using your own customer portal: this makes sense if you already have a customer portal, and wish to incorporate SLASCONE's functionality through API calls.
• using the SLASCONE customer portal: this is the fastest way.

MAXIMUM NUMBER OF LICENSES PER NAMED USER

Typically, a named user should only be able to be stored in only one license (per product), because otherwise, the client application would be forced to handle multiple licenses.

In order to facilitate all kinds of scenarios, you can set the maximum number of licenses per user in the Advanced Properties of a product. Please make sure you set this value carefully, because decreasing this value in a production system is not possible.

For the check it doesn't matter if a license is active or not. Only if the user within the license is active.

CLIENT/API CONSIDERATIONS

SaaS

In a SaaS scenario, you do not need a direct license activation process/event, since licenses are automatically activated upon creation.

B2B

When a user logs into a B2B SaaS application, typically the following method needs to be called:

POST ​/api​/v2​/isv​/{isv_id}​/provisioning​/licenses​/by_user

This method returns all licenses (typically just one) associated with the user trying to log in.

B2C

When a user logs into a B2C SaaS application, typically the following method needs to be called:

POST /isv/{isv_id}/provisioning/licenses/by_customer

This method returns an array of licenses (0-n) based on the customer_number. If the result is more than one active license, then the client application has to interpret the results accordingly (typically an additive logic is employed).

Alternatively, depending on what information is available on your backend during a user log in, one of the following methods might be relevant:

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

This method returns an array based on a license key (typically a subscription key).

On Premise

Web Apps

In terms of client/api considerations, the on-premise scenario is identical to the one for named devices described here.

The activation and heartbeat methods returns all license parameters, including the list of valid users.

Desktop Apps

When a user logs into a Desktop application, typically the following method needs to be called:

POST ​/api​/v2​/isv​/{isv_id}​/provisioning​/licenses​/by_user

This method returns all licenses (typically just one) associated with the user trying to log in. The desktop application needs to be activated (if still not activated). This is done by the application in the background, without the user having to do anything. Please note that, in such a scenario the number of license tokens is rather irrelevant and can be initialized to 1, since similar to floating scenarios, the application can be installed in any number of clients.

It is recommended to use a combination of unique hardware id and operating system user as your client_id, e.g., DEV6394_yourdomain\matthew. This adds an extra layer of protection, allowing you to distinguish between different users in a (terminal) server environment.

Preventing Account Sharing

Preventing account sharing in such scenarios (named user, desktop apps) is more challenging than in SaaS apps, since there is no common application backend to check this. Therefore, similar to floating scenarios, SLASCONE handles session management.

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

The API returns one of the following:

• Successful: A token has been assigned. The response body also includes the token validity (valid until).
• Conflict 12006: The number of allowed sessions for this user has been reached.

The maximum number of parallel sessions for a user (across devices) is controlled by the respective edition.

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.