Floating License Server Help

User restrictions

If you have users that should absolutely be able to get a license at all times, use white, black, and priority lists to configure their access. Floating License Server administrator can use username, hostname and other parameters to restrict user access to licenses.

Configuration

To configure user restrictions, create a access-config.json file containing access rules:

{ "whitelist": [ { "product": "(II|RSU|CL)", "userName": "windowsuser.*", "hostName": ".*.itdept.company.net" }, { "product": "RC", "buildNumber": "2011\\.2\\..+" } ], "blacklist": [ { "product": "RSU", "userName": "windowsuser12", "hostName": ".*user12.itdept.company.net" } ] }

Then, tell FLS to use it:

  1. Stop FLS
  2. Set the path to the configuration file:

    <fls_home>/bin/license-server.sh configure \ --access.config=file:/<path>/access-config.json
    where access-config.json is the configuration file with the restrictions specified as described above.
  3. Start FLS
  1. Stop FLS
  2. Set the path to the configuration file:

    <fls_home>\apps\license-server\bin\license-server.bat configure \ --access.config=file:\<path>\access-config.json
    where access-config.json is the configuration file with the restrictions specified as described above.
  3. Start FLS

Whitelist

Whitelist defines who is allowed to obtain licenses from your instance of FLS.

Empty Whitelist
Anyone not on the blacklist.
Non-empty Whitelist
Only users from the whitelist.

Blacklist

Blacklist defines who is not allowed to obtain licenses from your instance of FLS.

Empty Blacklist
Anyone on the whitelist.
Non-empty Blacklist
Only users from the whitelist that are not blacklisted.

Priority list

Priority list is a separate section, it has the same format as black or whitelist - it must contain either username, or hostname, or both. In the last case, the server will check strict matching for the pair.

{ "prioritylist": [ { "userName": "kate" } ] }

The algorithm of licenses requests handling if the access configuration file has the priority section:

  • If there are available licenses on the server suiting an IDE request and a user is not blacklisted - the IDE gets the ticket subject to standard procedure.

  • If there are no available licenses but the user is listed in the priority section - the floating server revokes one of the already occupied licenses and will grant it to the prioritized user. By default, the ticket whose "last-seen" is the oldest, will be revoked. This mechanism is not configurable.

LDAP integration

LDAP integration is enabled via the configuration file along with other rules:

{ "ldap": { "openLdap1": { "url": "ldap://", "masterDn": "", "password": "", "useSSL": false, "connectionTO": 20000, "responseTO": 30000, "minPoolSize": 1, "maxPoolSize": 5 } }, "whitelist": [ { "product": "IDEA", "ldap": "openLdap1", "matchCondition": "(&(objectCategory=user)(uid=${userName}))" } ] }

In this example the first section describes connection parameters and IntelliJ IDEA license will be granted only to users with usernames found in LDAP conf.

Multiple filters are supported:

"matchCondition": "(&(objectClass=user)(sAMAccountName=${userName})(memberOf=))"

If the integration is configured correctly during the license server's start there will be output (also in license-server-stdout.log):

INFO BlockingConnectionPool:326 - pool initialized [org.ldaptive.pool.BlockingConnectionPool@561062202::name=null, poolConfig=[org.ldaptive.pool.PoolConfig@1540665329::minPoolSize=1, maxPoolSize=5, validateOnCheckIn=false, validateOnCheckOut=true, validatePeriodically=true, validatePeriod=15, validateTimeout=5000], activator=null, passivator=null, validator=[org.ldaptive.pool.CompareValidator@732826732::compareRequest=[org.ldaptive.CompareRequest@232766788::compareDn=, attribute=[objectClass[top]], controls=null, referralHandler=null, intermediateResponseHandlers=null]] pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@630142260::prunePeriod=300, idleTime=600], connectOnCreate=true, connectionFactory=[org.ldaptive.DefaultConnectionFactory@1541061971::provider=org.ldaptive.provider.jndi.JndiProvider@4 connectTimeout=20000, responseTimeout=30000, sslConfig=null, useSSL=false, useStartTLS=false, bindSaslConfig=null, bindControls=null]]], initialized=true, availableCount=1, activeCount=0]

In whitelist section there is a product and "matchCondition" rule. FLS compares the username in the "obtainLicense" request sent by a product with usernames found in LDAP

Parameters

Parameters in access config file for products rules
  • product - available for black/white/priority lists and for LDAP rules

  • userName - for non LDAP rules

  • hostName - for non LDAP rules

  • buildNumber - available for black/white/priority lists and for LDAP rules (available from build #17768)

  • ldap - object with parameters to LDAP connect (available from build #17768)

  • matchCondition - for LDAP rules only.

  • ip - for non LDAP rules (available from build #18692)

  • checkLicenseOnly - make the rule's "product" parameter to be checked only against license product name and code, without an additional check of covered products. Value can be true or false (available from build #19340)

Parameters for LDAP integration credentials
  • url - required

  • masterDn - required

  • password - required

  • useSSL - optional

  • connectionTO - optional

  • responseTO - optional

  • minPoolSize - optional

  • maxPoolSize - optional

Codes and descriptions of licenses types which could be used in product parameter:

Name of Product/Pack

Example with code

Example with name

All Products Pack

"product": "ALL"

-

AppCode

"product": "AC"

"product": "AppCode"

AppCode

"product": "AC"

"product": "AppCode"

CLion

"product": "CL"

"product": "CLion"

DataGrip

"product": "DB"

"product": "DataGrip"

dotCover

"product": "DC"

"product": "dotCover"

dotMemory

"product": "DM"

"product": "dotMemory"

dotTrace

"product": "DP"

"product": "dotTrace"

GoLand

"product": "GO"

"product": "GoLand"

IntelliJ IDEA

"product": "II"

"product": "IntelliJ IDEA"

PhpStorm

"product": "PS"

"product": "PhpStorm"

PyCharm

"product": "PC"

"product": "PyCharm"

ReSharper

"product": "RS0"

"product": "ReSharper"

ReSharper Ultimate

"product": "RSU"

"product": "ReSharper Ultimate"

ReSharper C++

"product": "RC"

"product": "ReSharper C++"

Rider

"product": "RD"

"product": "Rider"

RubyMine

"product": "RM"

"product": "RubyMine"

WebStorm

"product": "WS"

"product": "WebStorm"

Examples

Case 1

{ "blacklist": [ { "product": "RS 2017.3", "userName": "(username1|username3|katya)", "hostName": “10.10.10.0” } ] }

In this case, a user WILL GET a license if:

  • The hostname is not 10.10.10.0;

  • Or username is not listed;

  • Or username is like katya123;

  • Or username is like username333;

  • Or product is not ReSharper;

  • Or product is ReSharper but 2017.2 / 2016.1 and so on.

Case 2

{ "whitelist": [ { "product": "RS 2017.3", "userName": "(username1|username3|katya)", "hostName": "10.10.10.0" } ] }

A user WILL NOT GET a license if:

  • They are among (username1|username3|katya), but hostname differs;

  • Or the user asks for anything but ReSharper;

  • Or for ReSharper but not version release 2017.3

  • Also, nothing will be available for other users although there is no separate blacklist section.

Case 3

{ "blacklist": [ { "product": "II 2017.2", "userName": "(username1|username2)" } ], "whitelist": [ { "product": "GO 2017.3", "userName": "(username3|username4|katya)" } ] }

In this case:

  • username1 and username2 - as well as users not listed in any section at all - will not get any license, because priority is given to whitelist rule.

  • If you need to restrict the access to anybody but (username3|username4|katya) and allow other users to keep on using other products - you need to remove the whitelist section and add a new one to the blacklist. To match users use regular expressions, etc:

    "product": "GO 2017.3", "userName": "((?!username3|username4|katya).)*"
    this rule will reject requests from all users who are not matched by usernames.

Case 4

{ "whitelist": [ { "product": "RSU", "userName": "user" }, { "product": "RS0", "userName": "user2", "checkLicenseOnly": "true" } ] }

In this case, user2 will get ReSharper only from single ReSharper licenses. Requests for other products from ReSharper Ultimate pack will fail and neither ReSharper Ultimate nor All Products Pack license will be given.

Last modified: 17 April 2019