An IdentitySelector is a way to test an identity against a set of criteria. This is a matching process, not a searching process. In other words, the criteria will be evaluated per identity while iterating over a list of identities. The criteria therefore do not need to be indexed or searchable and can even be complex expressions. The outcome of the matching process is a boolean true or false value indicating whether to include or handle the identity.
There are several places within IdentityIQ, where an IdentitySelector is or can be used to filter identities.
Some places are hidden, working in the background (see for example Controlling Identity Suggests with IdentitySelectors). Some are visible and configurable in the UI. Examples are:
- Advanced polices ("Selection method", see Policies),
- Automatic role assignment ("Assignment rule" in business roles),
- Selection of included identities in Lifecycle Events and Certification Events ("Identities included").
Types of IdentitySelector configurations
There are five ways to configure an IdentitySelector:
- Match List,
- Filter,
- Script,
- Rule,
- Population.
Apart from these options, sometimes the option "All" is presented. This effectively creates no IdentitySelector at all. In some other the option "None" is present. This also does not create an IdentitySelector. The part of the product where the IdentitySelector is used determines how the absence of an IdentitySelector affects the selection: match all or match none.
Match list
A match list based identity selector is very similar to an entitlement SOD policy, except:
- There is only one filter set and,
- Any account attribute can be used, even if it is not an entitlement.
The following image shows what a match list looks like in an advanced policy rule.
The two filter sets of an Entitlement SOD policy can be simulated by making two groups and applying the And expression to these groups. This would look like the image shown here:
Filter
The "Filter" type of the advanced rule is a so called "CompoundFilter". The expression always starts with <CompoundFilter> and ends with </CompoundFilter>. The actual filter expression is a Filter or CompositeFilter. A CompositeFilter can combine multiple Filters. In addition to the Filter or CompositeFilter, an additional section <Application>...</Application> can be used to refer to application definitions which attributes are used inside the filters. The filters refer to the applications using a numeric code, starting with 0: the position of the referred application in the list. The numeric code is followed by a colon and the attribute to be compared, e.g.: 0:memberOf. Identity attributes are used without any reference. If the Application section is omitted, the full name of the application must be used, e.g.: ExampleApp:memberOf.
An example filter, representing the same filter as the Entitlement SOD policy example and the match list example, would look like:
<CompoundFilter>
<Applications>
<Reference class="sailpoint.object.Application" name="OpenDS"/>
<Reference class="sailpoint.object.Application" name="Ubuntu"/>
</Applications>
<CompositeFilter operation="AND">
<CompositeFilter operation="OR">
<Filter operation="EQ" property="0:isMemberOf" value="cn=testgroup,ou=Groups,dc=pieters,dc=cx"/>
</CompositeFilter>
<CompositeFilter operation="AND">
<Filter operation="EQ" property="1:group" value="iiq"/>
<Filter operation="EQ" property="department" value="Software Testing"/>
</CompositeFilter>
</CompositeFilter>
</CompoundFilter>
An explanation of the CompoundFilter can be found in a separate document: CompoundFilter. More examples can be found in Examples of XML for a CompoundFilter in the UI.
Script and rule
Script and Rule are virtually the same. Both are BeanShell scripts and have the same input parameters and returns. The difference is where the BeanShell code is stored. In case of a Script based identity selector, the code is stored as part of the enclosing object (policy, role, etc.). In case of a Rule based identity selector, the code is stored in a separate Rule object and only a reference to this Rule is stored in the enclosing object.
For general information on writing BeanShell code refer to Writing Rules and Scripts and the BeanShell Developer's Guide for IdentityIQ.
The rule is supposed to return either true or false (boolean), where true means that a match has been found. In a policy rule, the script or rule may, instead of a boolean value, also return an object of type sailpoint.object.PolicyViolation. Returning null has the same effect as returning false.
Population
Probably the easiest variant of an identity selector is the population type. When this type is selected, only a drop down list is presented to select a pre-defined population.
Any identity that is a member this population is considered a match for the identity selector. A population can be created by searching identities with the desired criteria in the advanced analytics and storing the result as a population.
Once the population has been created, it is marked as private. Go to Define > Groups > Populations and open the population. The private mark can here be undone.
A downside of using a population for an identity selector may be that a population is rather static and cannot be changed easily. Once a population has been defined, it cannot be changed through the web user interface, but only by editing XML directly. An end user would have to create a new population and update the identity selector if the population definition needs to be changed. Removing a population and creating a new one with exactly the same name will break the identity selector definition. The population must be reconnected to the identity selector.
| Note: the text in this article has been derived from the wiki article on Policies and slightly rewritten to be more generic. The Policies article has been updated to point to this article. |
