The Identity Object & LDAP Groups

Leveraging the identity object and LDAP groups to drive security and form behaviors

In the Kinetic Platform 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.


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('') !== -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('') !== -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.