KSL was introduce in Kinetic Task 3.0, and is used as a strategy for defining and managing access control. For an overview of KSL in Kinetic Task, please see the Getting Started with KSL article in the Kinetic Task 3.0 User Guide.
The snippits shown below are intended to be examples for the most common KSL policies, and can be copied and pasted into the Kinetic Task source configuration console. For more information on writing your own KSL policies, see the KSL Reference article in the Kinetic Task 3.0 Developer Guides.
|Policy Message||no access is allowed to this resource|
This is a simple rule that will prevent all access the resources that it is applied to, and will respond with the static text no access is allowed to this resource.
Restrict to Localhost
|Policy Ruleemail@example.com_addr == '127.0.0.1'|
|Policy Message||access is restricted to localhost|
This rule will prevent access unless the request originated from the same machine that Kinetic Task is running on, and the request came over the loopback network interface (IE, the resource is being accessed using the IP address 127.0.0.1). The message is simple static text.
Restrict to IP Whitelist
|Policy Message||request does not originate from IP whitelist (<%= @request.remote_addr %>)|
This rule will prevent access unless the request originated from one of the "whitelisted" IP addresses (192.168.1.100, 192.168.1.101, or 192.168.1.102).
The message includes dynamic content, denoted by the <%= and %> tags. In this case, the address that the request originated from is inserted into the message.
Assuming the request came from 192.168.1.103, access to the resource would be denied and the message would evaluate to: request does not originate from IP whitelist (192.168.1.103)
Restrict to Subnet
|Policy Rule||require 'ipaddr' |
range = IPAddr.new('192.168.1.0/24')
|Policy Message||request does not originate from required subnet|
This rule is an example of a complex policy rule, and will prevent access to any request originating from an IP address outside the range of 192.168.1.0 to 192.168.1.255. The last statement in a policy rule (in this case the range.include? line) specifies whether access to the resource is allowed or not, but a policy rule may contain multiple statements. In the case of this rule, the 'ipaddr' library is being loaded (which defined the IPAddr helper) on the first line, a new ip address range is created on the second line, and the last statement returns whether the range includes the IP address that the request originated from.
Require Security Token
|Policy Rulefirstname.lastname@example.org_header("X-Security-Token") == "SuPeRsEcReT"|
|Policy Message||<%= |
if @request.get_header("X-Security-Token") == nil
"security token not provided"
"security token mismatch"
This rule compares the X-Security-Token request header to a static value SuPeRsEcReT and denies access if the security token header is missing or doesn't match.
The policy message is selected dynamically, which indicated by the <% and %> tags. If the X-Security-Token request header is missing, the message will be security token not provided. If the request header is present and doesn't match, the message will be security token mismatch.