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 desirableuserName
. 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
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
, orkatya
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.
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
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
licenseThe username matches the regular expression, for example,
student123
The user's IP is in the range from
172.35.152.0
to172.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.
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
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
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 |
---|---|
| Required parameter which defines the LDAP server address, the value must contain the domain controller |
| Required parameter which defines the account of the domain |
| Required parameter which defines the password for the account |
| Optional parameter which defines whether to use SSL |
| Optional parameter which defines the connecting time to LDAP in milliseconds |
| Optional parameter which defines the time for getting response from LDAP in milliseconds |
| Optional parameter which defines the minimum pool size |
| Optional parameter which defines the maximum pool size |
LDAP configuration example
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 |
|
AppCode |
|
CLion |
|
DataGrip |
|
DataSpell |
|
dotCover |
|
dotMemory |
|
dotTrace |
|
dotUltimate |
|
GoLand |
|
IntelliJ IDEA |
|
PhpStorm |
|
PyCharm |
|
ReSharper |
|
ReSharper Ultimate |
|
ReSharper C++ |
|
ReSharper Ultimate + Rider |
|
Rider |
|
RubyMine |
|
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 stopSet 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.jsonStart FLS using the following command:
./bin/license-server.sh startCheck 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.jsonAlso, 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 stopSet 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.jsonStart FLS using the following command:
./bin/license-server.sh startCheck 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.jsonAlso, 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.jsonStart 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.jsonAlso, 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.
To find the location of your log files, see Check configuration.