User restrictions

If you need to restrict someone's access to licenses, or you have prioritized users, who should get a license even if there are none available, the FLS administrator can configure user restrictions. When a user wants to obtain a license, the IDE sends a request to License Server. This request is compared to the set of rules defined by the FLS administrator, and a license is either granted or rejected.

To set user restrictions, create the access-config.json file and specify its path.

The access-config.json file consists of one or several lists of rules: the whitelist, the blacklist, and the priority list. Each rule is a set of conditions that should all match to trigger the rule. Depending on type of the list, the triggered rule will either grant or reject a license for the received request. Use the following parameters to configure the rules.

Parameters for rules

product

Defines the product names to which this rule is applied. The value can be a product name or a regular expression. FLS converts the value of this parameter to the .*<value>.* regular expression during the preprocess, that's why the value will be compared to the whole string. So, do not use the symbol of the beginning of a string (^) and a symbol of the end ($) of a string.

userName

Defines the user that launched an IDE. The value can be a plain username or a regular expression. You can configure it into IDE by adding the user.name option to custom properties with the desirable userName. This parameter can't be configured in the same whitelist as LDAP integration.

hostName

Defines the user's host name. The value can be a plain hostname or a regular expression. This parameter can't be configured in the same whitelist as LDAP integration.

buildNumber

Defines the product build number. The value should be a regular expression (available from build #17768).

ip

Defines the user's IP address. The value should be a regular expression. FLS supports IPv4 (available from build #18692). This parameter can't be configured in the same whitelist as LDAP integration.

checkLicenseOnly

Defines whether to apply the rule only to a single license without checking product pack licenses, see Filtering by single product license (available from build #19340).

ldap

Defines the name of LDAP configuration. This parameter is required when LDAP integration is configured (available from build #17768).

matchCondition

Defines rules for LDAP search. This parameter is required when LDAP integration is configured (available from build #17768).

Blacklist

The blacklist defines who is prohibited from obtaining licenses. This list consists of a number of rules, where each rule is a set of conditions. If the request matches all the conditions of at least one rule, FLS reject the request.

Blacklist example with two rules

{
    "blacklist": [
        {
            "product": "GoLand"
        },
        {
            "product": "II",
            "buildNumber": "^2017\\.3.*",
            "userName": "(username1|username3|katya)",
            "hostName": "username.company.net"
        }
    ]
}

In this case, a user will not get a license if one of the following rules is matched:

The requested product is GoLand
The request matches all the following conditions:
- The product is IntelliJ IDEA
- Product version is 2017.3
- The username is username1, username3, or katya
- The hostname is username.company.net

Blacklist example with a negation of the regular expression

If you want to restrict access to GoLand for any users, except username3, username4, and katya and allow them to use other products, add the following rule to the blacklist.

{
    "blacklist": [
        {
            "product": "GO",
            "userName": "(?!username3|username4|katya).*"
        }
    ]
}

This rule will reject requests from all users who are not matched by userName and want to obtain a GO license.

Even if there are available All Products Pack licenses or any other pack licenses that covers the restricted product, you won't get access when your request matches the blacklist rule.

To learn how the blacklist and whitelist work at the same time, read using the blacklist and whitelist together.

Whitelist

The whitelist defines who is allowed to obtain licenses. This list consists of a number of rules, where each rule is a set of conditions. If the request matches all the conditions of at least one rule, FLS grants a license. Creating the whitelist means that all requests that don't match any whitelist rule will be rejected.

Whitelist example with one rule and regular expressions

{
    "whitelist": [
        {
            "product": "ALL",
            "userName": "student[0-9]*",
            "ip": "172\\.35\\.152\\..*"
        }
    ]
}

In this case, a user will get a license if all the following conditions are fulfilled:

The requested product is included in All Products Pack license
The username matches the regular expression, for example, student123
The user's IP is in the range from 172.35.152.0 to 172.35.152.255

To learn how the blacklist and whitelist work at the same time, read using the blacklist and whitelist together.

Using the blacklist and whitelist together

If both the whitelist and blacklist are configured, the blacklist has higher priority. When a request matches rules in both lists, the license request is denied.

{
    "blacklist": [
        {
            "product": "GO",
            "buildNumber": "^2018\\.3.*",
            "userName": "(username1|username2)"
        }
    ],
    "whitelist": [
        {
            "product": "GO",
            "userName": "(username2|username3|username4)"
        }
    ]
}

Although username2 is mentioned in the whitelist, this user will not get a license for GoLand 2018.3, because the blacklist has higher priority. However, if username2 requests another version of GoLand, this user will obtain a license.

Priority list

If you have prioritized users, which should have access to licenses even if there are none available, configure the priority list. FLS revokes someone else's license, whose last-seen parameter is the oldest, and grants the license to the prioritized user. This mechanism of choosing who will lose the ticket is not configurable.

The priority list is a separate section, which has the same format and mechanism of matching rules as the blacklist and whitelist. It must contain at least one of these parameters: userName, hostName, or ip. Other parameters are optional.

Priority list example with one user

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

In this case, if no licenses are available, FLS grants one already taken license to kate. In case when all the existing licenses in a pool are obtained by prioritized users, one more request from prioritized user will be denied.

Filtering by single product licenses

Since FLS supports JetBrains ToolBox licensing model, a user can obtain a subscription pack license. For example, ReSharper license can be a single license or can be covered by All Products Pack, ReSharper Ultimate, ReSharper C++, dotUltimate, and ReSharper Ultimate + Rider licenses. If you want a rule to apply only to single ReSharper licenses, enable the checkLicenseOnly parameter.

CheckLicenseOnly example

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

In this case, user2 can get ReSharper only from single ReSharper licenses, but not as a part of a product pack.

This parameter can be applied to any other product that is covered by any license packs.

LDAP integration

LDAP, the Lightweight Directory Access Protocol, is the mechanism to interact with directory servers. If your organization uses LDAP, you can configure access rules filtering requests by LDAP accounts. Enable its usage by configuring a separate block in access-config.json. It has its own set of parameters.

Parameter	Description
`url`	Required parameter which defines the LDAP server address, the value must contain the domain controller
`masterDn`	Required parameter which defines the account of the domain
`password`	Required parameter which defines the password for the account
`useSSL`	Optional parameter which defines whether to use SSL
`connectionTO`	Optional parameter which defines the connecting time to LDAP in milliseconds
`responseTO`	Optional parameter which defines the time for getting response from LDAP in milliseconds
`minPoolSize`	Optional parameter which defines the minimum pool size
`maxPoolSize`	Optional parameter which defines the maximum pool size

LDAP configuration example

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

In this example the first section describes LDAP connection parameters. IntelliJ IDEA license will be granted only to users with usernames found in LDAP records. The url parameter should consist of LDAP host, port, and a list of domain controllers. Here FLS connects to the LDAP where the host is domain, port is 389, and the root is company.org.

In the whitelist section there is a matchCondition parameter which defines rules for LDAP search. The only available placeholder is ${userName} which inserts the username from the license request to the search.

Product names reference

The product parameter uses the following syntax to designate product names:

Product	Value
All Products Pack	`"ALL"`
AppCode	`"AC"` or `"AppCode"`
CLion	`"CL"` or `"CLion"`
DataGrip	`"DB"` or `"DataGrip"`
DataSpell	`"DS"` or `"DataSpell"`
dotCover	`"DC"` or `"dotCover"`
dotMemory	`"DM"` or `"dotMemory"`
dotTrace	`"DPN"` or `"dotTrace"`
dotUltimate	`"DUL"` or `"dotUltimate"`
GoLand	`"GO"` or `"GoLand"`
IntelliJ IDEA	`"II"` or `"IntelliJ IDEA"`
PhpStorm	`"PS"` or `"PhpStorm"`
PyCharm	`"PC"` or `"PyCharm"`
ReSharper	`"RS0"` or `"ReSharper"`
ReSharper Ultimate	`"RSU"` or `"ReSharper Ultimate"`
ReSharper C++	`"RC"` or `"ReSharper C++"`
ReSharper Ultimate + Rider	`"RRR"` or `"ReSharper Ultimate + Rider"`
Rider	`"RD"` or `"Rider"`
RubyMine	`"RM"` or `"RubyMine"`
WebStorm	`"WS"` or `"WebStorm"`

Removing rule or condition

To delete configured list of rules, or a condition, remove an appropriate line or code block from the access-config.json file. For example, if you need to remove the whitelist, delete this entire section.

Before	After
{ "blacklist": [ { "product": "GO", "buildNumber": "^2018\\.3.*", "userName": "username" } ], "whitelist": [ { "product": "GO", "userName": "username" } ] }	{ "blacklist": [ { "product": "GO", "buildNumber": "^2018\\.3.*", "userName": "username" } ] }

Configuration

After you create the access-config.json file, specify its path in the FLS configuration file. We recommend you to locate this file in the FLS installation directory under conf.

Change to the FLS installation directory using the command line.
Stop FLS using the following command:
./bin/license-server.sh stop
Set the path to the access-config.json file.
For example, if it is located in the FLS installation directory /opt/fls-home/ under conf, run the following using the command line.
./bin/license-server.sh configure \ --access.config=file:/opt/fls-home/conf/access-config.json
Start FLS using the following command:
./bin/license-server.sh start
Check that you specified the path correctly, and the file itself is clearly written. If you made a mistake creating rules, or defined the wrong path, you should see the error message similar to the following in your log files.
Failed to parse config located at /opt/fls-home/conf/access-config.json
Also, the FLS dashboard shows the message Problem loading access config file in case of bad performance.

Change to the FLS installation directory using the command line.
Stop FLS using the following command:
./bin/license-server.sh stop
Set the path to the access-config.json file.
For example, if it is located in the FLS installation directory /opt/fls-home/ under conf, run the following using the command line.
./bin/license-server.sh configure \ --access.config=file:/opt/fls-home/conf/access-config.json
Start FLS using the following command:
./bin/license-server.sh start
Check that you specified the path correctly, and the file itself is clearly written. If you made a mistake creating rules, or defined the wrong path, you should see the error message similar to the following in your log files.
Failed to parse config located at /opt/fls-home/conf/access-config.json
Also, the FLS dashboard shows the message Problem loading access config file in case of bad performance.

Stop FLS using the JetBrains License Service.
Services Microsoft Management Console (MMC) (Control Panel > Administrative Tools > Services > JetBrains License Service)
Change to the FLS installation directory using the command line.
Set the path to the access-config.json file.
For example, if it is located in the FLS installation directory C:\fls-home\ under conf, run the following command.
.\apps\license-server\bin\license-server.bat configure ^ --access.config=file:\C:\fls-home\conf\access-config.json
Start FLS using the JetBrains License Service.
Check that you specified the path correctly, and the file itself is clearly written. If you made a mistake creating rules, or defined the wrong path, you should see the error message similar to the following in your log files.
Failed to parse config located at /opt/fls-home/conf/access-config.json
Also, the FLS dashboard shows the message Problem loading access config file in case of bad performance.

If you configured LDAP integration correctly, when you start FLS, report similar to the following will be logged to 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]

To find the location of your log files, see Check configuration.

Last modified: 25 August 2023