NAMED USER LICENSES

Named user licensing is a common requirement, that is typically found in

• SaaS applications: there is only one backend, receiving all incoming requests. Only one physical installation communicates with SLASCONE. The user id (username or email address) has to be unique across all end-customers.
• 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.

In both cases, one license per end-customer is necessary. This one license entitles 1:n end-users.

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 2 users. Although, you can add as many users as you want, only 2 can be active.

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.

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. When a user logs into the SaaS application, only 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.

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_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).

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

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

On Premise

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.

CODE EXAMPLES

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