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.
// 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.
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')
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.