The Top 5 limitations when you use SailPoint IdentityIQ's Reporting Framework:

 

Limitation 1: You Always Use the IdentityIQ Application Database

​

If you have a lot of data (which most identity governance implementations do) and have a considerable number of users running frequent reports, all reports are hitting your internal database.

 

Each time you run a report, you are taking processing power away from the application database. And within SailPoint, all report and analytics queries are inherently run against this read-write database. The SailPoint “context” used for reporting and analytics cannot query another database. You could create custom JDBC connections in your reports but that’s a lot of effort with limited flexibility. With “Advanced Analytics” you don’t even have that option.

​

 

Limitation 2: Your Data Access is Limited to What's Supported By the APIs

All IdentityIQ reports and analytics use the product’s API or built-in data sources only. This may not be a limitation if you are a business user but ask your SailPoint developers if they feel restricted when using IdentityIQ API and built-in data sources when customizing reports.

​

SailPoint does not provide direct access to its database from its interface. The schema is hidden within the Hibernate interface. This has its benefits but when you want to get data from multiple tables which are not linked in the product API, you end up running multiple iterations of API calls to get the data you need. This not only reduces your performance but also significantly increases the load, both on your application and your database.

 

And even if you would revert to using custom data sources and SQL queries in your reports, a lot of data within SailPoint is stored in XML. To present this data in a legible format, you need API calls again.

 

Limitation 3: You Do Not Have Column Level Security

While SailPoint does provide row-level security, column-level security is not supported unless you create multiple versions of the same report. Say you want to create a “Users” report but only show the Pay Grade to the HR folks and everything else to the Managers, you will have to create multiple versions of the report. One for the Managers and one for HR.

​

Now imagine the iterations of similar reports you would need to create in a large enterprise. This takes significant time away from your Development team. They get tied down with meeting operational demands instead of on-boarding new applications and implementing additional functionality.

 

Remember, this has a domino effect on the ROI of your identity governance implementation.

This column / attribute level security capability is also not available in the product’s Advanced Analytics feature. You either get access to all the attributes of a data set or none.

 

Limitation 4: You End Up With Maintenance Overload for All Custom Reports

Because of the way IdentityIQ's reporting functionality is designed, all customizations and subsequent iterations require a lot of development effort. The reporting interface does not provide capabilities like “starts with”, “ends with”, “contains” etc. This combined with no column/attribute level access control, you may end up with many variations of the same report.

 

Maintaining these reports becomes a full-time responsibility for your Development team.

The “Advanced Analytics” feature has the “starts with”, “ends with”, “contains” etc. functionality but you are potentially giving way more access to users than they need.

 

Limitation 5: Your Storage Needs Grow Exponentially

IdentityIQ’s report results are stored as Task Results. If your users have not configured to auto-delete (overwrite) the data from their previous reports, these report results can add up really quick.

And even if they did overwrite the previous report result, in large enterprises with huge amounts of data and many users running reports, the impact on the storage capacity of your SailPoint environment is significant.

​

 

How do you overcome these limitations?

 

And not only overcome, but how do you provide a more robust and rich reporting interface to your business, information security and operational users, while reducing the maintenance overhead for your Development team?

 

The answer, you externalize it.

 

You would ideally create a read-only replica of a few database tables and offload all your reporting functionality to it. Then you setup a business intelligence tool on top of it to extend and enhance your reporting capabilities.

​

Let’s see what all this accomplishes and how:

1. Double the Performance:

You get better IdentiyIQ application and reporting performance because both those functionalities are now segregated into separate systems, both the application and database tiers. Your identity application focuses on identity management and governance, while the business intelligence focuses on, well business intelligence and reporting. Moreover, the reports and their outputs are not stored within SailPoint either. This further reduces the load on the SailPoint application and its database.

​

2. Immense Flexibility:

With direct access to the SailPoint database and other data sources, you get a vast amount of flexibility as to how and from where you pull your data. And because you are using a read-only replica, and/or a read-only account, there is no possibility of inadvertently corrupting the SailPoint data.

While you may ask that the database schema might change but the API may not so you may have to rework the reports etc. Well, that has not been our experience so far. IdentityIQ’s database schema has more or less remained similar to its previous releases, while the API has seen frequent improvements and deprecations. You can create custom queries and pull data from multiple tables and are no longer constrained by the product’s API, however rich it be.

 

3. Granular Security:

While you can implement row-level security in SailPoint reports with some customization, implementing column-level security based on user identity and role isn’t trivial. In out-of-the-box reports its just not possible. You will need to create custom reports. And even then, the report task definition cannot be modified in runtime. You will just need to show an empty column in the output, which is not a great user experience.

With a business intelligence tool you can control access at data source, report, row, and column levels, based on a user’s identity, group or role membership. This greatly simplifies and strengthens your data access security model.

​

4. Minimum Maintenance Overhead and Development Time:

SailPoint at its core is an identity governance tool and its great at that. Reporting within SailPoint while rich, is not its core functionality or feature. That is why using a separate Business Intelligence tool makes so much sense. Because querying data and creating reports is the core feature of a Business Intelligence tool, creating custom and rich reports is easy, and updating them is quick. You reduce a lot of overhead in maintaining custom reports.