Our Complex Role Membership Plugin is a standalone IIQ add-on, allowing you to automatically assign roles to identities in SailPoint IdentityIQ using complex, configuration-based criteria. The plugin can evaluate hundreds of roles with hundreds of criteria. It also supports dynamic, complex grace period end dates for role assignments. It has been a critical part of our successful IdentityIQ implementations in higher education.
While we created this plugin to manage roles, it can also easily maintain multi-valued Identity attributes, such as automatically determining a list of academic affiliations, bank branches, or personas.
Complex criteria
The CRMP can, via configuration alone, assign roles or populate Identity attributes based on any combination of these criteria – called “Selectors”:
- Identity attribute filters
- Account attribute filters
- Account existence (or account in a particular state, like Enabled AD Account)
- Entitlements
- IIQ Populations and Workgroups
- Assigned or detected roles
- Capabilities or rights
- HQL and SQL queries
- Beanshell rules or scripts
You may cluster and combines Selectors using boolean operations, with a convenience syntax for your common “all except” use cases. Common criteria can be given a name, then included within any other Selector logic.
Over the years, our developers have made the Complex Role Membership Plugin extremely efficient. The CRMP compiles your Selectors into a tree of native Java objects, making repeated evaluations rapid and accurate. Even in the largest installations, with the CRMP controlling hundreds of roles via dozens of Selectors each, a role membership refresh only takes a small fraction of a second.
The VPN problem
When I’m interviewing candidates for SailPoint IdentityIQ work, I often ask about the following real IIQ use case:
How would you configure an IIQ Role with the following criteria? The role should be granted if the Identity’s hrStatus is Active, unless the Identity has AD entitlements “VPN Override” or “IT VPN”.
This isn’t just complex for the sake of an interview. This sort of “all except” role structure is common when provisioning to a variety of systems. In this case, the VPN system could only handle membership in a single AD group to control access; having two would disable access altogether. IIQ doesn’t have a great way to handle these situations without writing custom Beanshell.
To resolve the interview problem with the CRMP, we can simply define the following:
<entry key="Default VPN User">
<value>
<Map>
<entry key="if" value="Filter: hrStatus == "Active""/>
<entry key="unless" value="Entitlement: VPN Override, IT VPN"/>
</Map>
</value>
</entry>That’s it.
Higher education
Complex, nested role assignment logic is very common in higher education. The higher ed community has even developed a powerful software tool entirely for group automation: Grouper. While we’ve assigned IIQ roles via Grouper at several institutions, this option isn’t always available, or desired. For security and efficiency, it is good practice to assign IAM roles close to the authoritative data sources and within the same system doing the provisioning.
Instrumental Identity has customers using over 100 selectors to assign hundreds of roles. This allows IdentityIQ to replace their previous (in-house) IAM systems with minimal overhead. The CRMP can be used to assign access based on university affiliation, course registration, or other complex criteria. CRMP selectors are often used to determine academic affiliation in the first place.
This diagram illustrates a stripped-down role assignment use case that would be trivial and human-readable with the CRMP. The colors and font indicate which type of selector you might use for each.
Grace periods
The CRMP also supports grace periods.
IIQ customers frequently need to retain certain access for a period of time after the identity no longer meets the criteria. Students, for example, may retain their university email for one calendar year. Employees may retain access to payroll systems until the following pay period ends.
When a role would ordinarily be de-provisioned (by no longer matching its criteria), the CRMP allows us to define a static number of days to retain access. Alternatively, in complex cases, a Beanshell script or a Java class can calculate an end date programmatically. The role will be removed automatically when its grace period has elapsed. (If needed, it could be removed earlier by some another process.)
This configuration will assign the role “Payroll Users” when the Identity is active and has a userType of Employee. When either Selector fails to match, the role would ordinarily be revoked immediately, but with this configuration, removal will be delayed for 30 days.
<entry key="Payroll Users">
<value>
<Map>
<entry key="if">
<value>
<String><![CDATA[
{Identity Status: Active} && {Filter: userType == "Employee"}
]></String>
</value>
</entry>
<entry key="Grace Period">
<value>
<Map>
<entry key="days" value="30"/>
<entry key="sticky" value="true"/>
</Map>
</value>
</entry>
</Map>
</value>
</entry>