Skip to main content
Kinetic Community

Using Identity and LDAP Groups

Overview

In Kinetic Request CE you can access a variety of information about the user from the "identity" object. This object is available in a number of places for use. Most commonly you'll want to use this for authorization in KSL policies but you can also use it for form conditions.

Details

In Kinetic Request CE you can access a variety of information about the user from the "identity" object. This object is available in a number of places for use. Most commonly you'll want to use this for authorization in KSL policies.

You access the identity information by calling the function. You will see our examples use the indexOf function a lot. This function is a basic JavaScript function available on strings and arrays that tells you where the argument has occurred. If it fails to find the argument (such as the email address domain) it will return -1. A common example is:

// Allow users whose email ends with your email domain.
identity('email').indexOf('@kineticdata.com') !== -1

If you have configured LDAP to automatically update the identity information and have mapped the attributes you will have access to:

  • identity('username') - a string containing the username that logged in.
  • identity('email') - a string containing the user's email address.
  • identity('displayName') - a string containing the user's name.
  • identity('groups') - an array of strings where the strings contain group names.

The groups values will not contain any groups that a user is indirectly a member of, such as through nested groups. Because identity('groups') returns a basic array of strings you can use any of the array and string functionality that JavaScript gives you out of the box. Take the email example above. You could create a KSL rule that looks like the following:

identity('groups').indexOf('Employee') !== -1

You're not limited to simple expressions. The KSL and conditions in Core Edition must always evaluate as an expression - that is taken as a whole the expression must return true or false. You can continue to refine the expressions with && (and) and || (or) operators and you can group expressions with parenthesis. Here's an example where you want to allow all employees who are not contractors:

identity('groups').indexOf('Employee') !== -1 && identity('groups').indexOf('Contractor') === -1

You can make the expressions increasingly complicated:

// Only allow employees who are not contractors
(identity('groups').indexOf('Employee') !== -1 && identity('groups').indexOf('Contractor') === -1)
  && identity('groups').indexOf('Infrastructure Admins') !== -1 // And are infra admins.

Remember that these expressions "short circuit". For example:

identity('groups').indexOf('Employee') !== -1 || 
  (identity('email').indexOf('@kineticdata.com') !== -1 && invalid.indexOf('thing')

The example above has an obvious flaw. The "invalid" variable doesn't exist and this expression should fail pretty loudly. Due to the nature of JavaScript if you only ever test this with a user who is in the group "Employee" the engine will never evaluate the second half of the expression. Always be aware of this when writing these rules.

You can also use these expressions outside of KSL. For example you can create a section in the Form Builder and set the Visible Condition to something like:

identity('groups').indexOf('VMware Admins') !== -1

Then this section and any of the elements inside of it will only be visible to users who are member of the VMware admin group. Please note that this is not a form of security. If these users have access to see the form they can potentially see the values in hidden fields. This only manipulates visibility in the form.

Using Kinetic Security Language for Authorization
Learn how Kinetic Request Core Edition goes beyond conventional role based policies for authorization using Kinetic Security Language (KSL) to build advanced authorization rules.
Security Definitions
Add Security with KSL to different parts of Kinetic Core and related Kapps.
How to use SSL with the LDAP bridge
This article describes the steps required to configure how to use SSL with the LDAP bridge including exporting / importing certificates.
Configuring LDAP Support
How to set up Request CE to authenticate set up users against an LDAP system instead of the local password store.
Kinetic Core Security Configuration
Getting Started with KSL
The Kinetic Security Language (KSL) is a strategy for defining and managing access control.  At a high level, KSL uses the same technology as the task handler parameters and connectors in order to determine whether a request should be allowed or denied.  Kinetic Task 3.0 leverages KSL to restrict API access, however usage of KSL will grow to be used in many other areas in both Kinetic Task and other Kinetic products.
Getting Started with KSL
The Kinetic Security Language (KSL) is a strategy for defining and managing access control.  At a high level, KSL uses the same technology as the task handler parameters and connectors in order to determine whether a request should be allowed or denied.  Kinetic Task 3.0 leverages KSL to restrict API access, however usage of KSL will grow to be used in many other areas in both Kinetic Task and other Kinetic products.
Getting Started with KSL
The Kinetic Security Language (KSL) is a strategy for defining and managing access control.  At a high level, KSL uses the same technology as the task handler parameters and connectors in order to determine whether a request should be allowed or denied.  Kinetic Task 3.0 leverages KSL to restrict API access, however usage of KSL will grow to be used in many other areas in both Kinetic Task and other Kinetic products.