Best practices for working with a large entitlement catalog in IdentityIQ

9 Kudos

What is considered a "large" entitlement catalog?
How large entitlements can occur
Issues with large entitlements
Best practices for working with large entitlements
Cleanse the data on managed systems before aggregating
Identify areas of risk - what really needs to be certified?
Use filtering in your connector applications to control what entitlement data is aggregated
Use groups and roles to encapsulate entitlements
Test properly using production data
Stagger certifications where possible
Exercise caution with rules in your certifications
Related

What is considered a "large" entitlement catalog?

When we talk about a large entitlement catalog in IdentityIQ, this means a quantity of entitlements in an IdentityIQ installation that is large enough to place a significant burden on systems (performance and processing time) or on people (number and complexity of access reviews to view and process) when a certification is run. There isn’t a specific threshold for the number of entitlements in an IdentityIQ system that must be met in order for the term “large entitlements” to apply; rather, the particulars of environment hosting the data, and the expectations of end users about how much time it will take to manage the data, are what can make an environment’s count of entitlements a challenge.

Note: A large entitlement catalog is sometimes referred to simply as "large entitlements" in IdentityIQ, and also in this document.

When considering the burden on systems, the IdentityIQ hardware sizing guide on Compass can give you some guidance about the right level of hardware for your IdentityIQ installation in general. However, this guide doesn’t provide detailed guidance about hardware sizing for a large entitlement catalog, since the size of the entitlement catalog isn’t typically known at the time of hardware planning. As a general rule of thumb, the Hardware Sizing Guide assumes 10-50 entitlements on average per identity.

How large entitlements can occur

There are many ways an IdentityIQ installation can end up with a significantly large entitlement catalog. In some cases it is as simple as having a very large number of identities and applications (with their attendant entitlements) managed by the IdentityIQ system.

In other cases, particular features or qualities of an application managed by IdentityIQ can cause "entitlement explosion" – for example:

Some source applications such as RACF and SAP allow you to include "fine-grained" permissions or entitlements with the data you aggregate. These can grow to hundreds or thousands of individual entitlements in your entitlement catalog.
File permissions: if you aggregate permissions on an object such as a file or folder, you may end up with individual entitlements for specific operations such as read, write, edit, delete, etc., on every object in the source system.

Issues with large entitlements

The main issues with large entitlements are the processing burden they place on the IdentityIQ system during certifications, which translates to time required for generating certifications, and also the reviewing burden they place on individual reviewers during a certification.

It is easy to see how an IdentityIQ installation that manages millions of users, and hundreds or thousands of applications, can end up with a really large entitlement catalog. It's also easy to see how a certification of all these entitlements will create huge volumes of data and will require individual approvers to process significant volumes of approvals - which might take days or even weeks to complete. If, for example, an individual manager need to certify entitlements for a team of 20 employees, and the entitlement catalog includes “fine-grained” permissions numbering in the thousands for each employee, the manager could easily need to spend several full days clicking through each entitlement and making decisions on whether to approve, reject, delegate, etc.

In addition, the choices made when the certifications are created can add processing time for IdentityIQ, before the reviewers even begin their work. Things like pre-delegation rules, partitioning settings, and even the chosen schedule for a certification (for example, choosing to certify everything in the system at once versus staggering certification campaigns across a longer time period) can significantly impact system performance.

Best practices for working with large entitlements

These best practices can help minimize the overhead of working with large entitlements. When in doubt, consult with your implementation manager or with Expert Services for additional guidance.

Cleanse the data on managed systems before aggregating

Cleansing data before aggregating from a managed system can help prevent "entitlement explosion" before it starts. Check for data that is obsolete, inaccurate, duplicated, or not relevant before aggregating. Get tips on cleansing data.

Identify areas of risk - what really needs to be certified?

Not every entitlement in IdentityIQ needs to be included in your certifications. Make sure you are only aggregating the permissions and entitlements that you intend to manage within IdentityIQ. You should also avoid certifying any entitlements that can't actually be revoked. Likewise, entitlements that will universally be allowed to every identity in IdentityIQ may not need to be certified.

Use filtering in your connector applications to control what entitlement data is aggregated

Related to the best practices of cleansing data and identifying areas of risk - you can in some cases set filters in your connectors to avoid aggregating entitlement data that does not need to be managed during certification. Review the relevant product documentation for the connectors you use, to understand your filtering options.

Use groups and roles to encapsulate entitlements

Groups and roles can help streamline your certification process, by encapsulating sets of entitlements; this can significantly reduce the number of individual items the reviewers need to process in each certification.

Test properly using production data

In your test phase, you should use full production data in order to do real, meaningful scale testing. The test phase should also encompass the entire certification process: generation, decisions/approvals, and resolution.

Stagger certifications where possible

Rather than doing all certifications at once, "chunk" your certifications and spread them out over time, to reduce the burden on both systems and people.

Exercise caution with rules in your certifications

Rules are useful for controlling how you want a certification to operate, but be aware that rule logic can add processing overhead to a certification. For example, say you wanted to certify entitlements for a set of your employees using a Population, and you wanted to delegate review to the line manager of each employee. You could accomplish this in two ways: by creating an Advanced Certification using a Population to select the employees and a pre-delegation rule to assign reviewing to the line managers, OR, by selecting the exact same set of employees (identities) in Advanced Analytics, then selecting Schedule Certification from the Advanced Analytics screen and choosing "Assign to Manager" (no pre-delegation rule is required in this case). If the data set (identities and entitlements both) is very large, the second option has been shown in the field to generate the certification significantly faster than the first option.

Best practices for working with a large entitlement catalog in IdentityIQ