Here's why you should externalize your SailPoint reporting, and what a simple design change gets you:
- Faster reports, and a faster SailPoint application
- Less development overhead for your identity team
- Richer reports, with features like drill-down and heat maps
- Tighter, more visible data access security
- Happier end users and management
SailPoint was one of the top, if not the top, identity governance products on the market when I wrote this (2022). And rightly so. The identity governance capabilities of the product are top-notch. Access certifications, provisioning validations, and fully customizable workflows all make SailPoint an excellent product.
SailPoint also has a robust Reporting and “Advanced Analytics” feature which is fine for small and simpler implementations. It does have a few limitations, though, which I list below.
However, with the right system in place, you can not only overcome these limitations but enhance your reporting capabilities, for both your business and your technical users.
Limitation 1: It Uses Your Internal SailPoint Database
This is the biggest limitation and drawback of using SailPoint’s built-in reporting and analytics capabilities. If you have a lot of data (which most identity governance implementations do) and have a considerable number of users running frequent reports, all these reports are hitting your internal database.
SailPoint is a write-heavy application, constantly writing requests, audits, workflows, certifications, and more to the database. Each time you run a report, you are taking processing power away from the read-write side of the functionality. 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: Data Access is Limited to APIs and Built-In Data Sources Only
All SailPoint’s 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 SailPoint developers if they feel restricted when using SailPoint’s 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 data from multiple tables that are not linked in the product API, you end up running multiple iterations of API calls to get the data you need. That hurts performance and significantly increases the load, both on your application and your database.
And even if you fall back to 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: No Built-in Column Level Security
While SailPoint does provide row-level security, column-level security is not that straightforward. Say you want a “Users” report that shows Pay Grade only to HR, and everything else to Managers. You will have to create multiple versions of the report: one for 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: Significant Maintenance Overhead with Custom Reports
Because of the way SailPoint’s reporting functionality is designed, all customizations and subsequent iterations require a lot of development effort. The reporting interface does not offer filters like “starts with”, “ends with”, or “contains”. Combine that with no column-level access control, and you 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 does have “starts with”, “ends with”, and “contains” filters, but you may be giving users far more access than they need.
Limitation 5: Report Outputs are Stored Within SailPoint
SailPoint’s report results are stored as Task Results. If users haven't configured reports to overwrite their previous results, these results add up quickly.
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.
To summarize, these are the limitations we have covered with using SailPoint’s built-in reporting and analytics capabilities:
- Uses your internal SailPoint database
- Data access is limited to APIs and built-in data sources
- No built-in column-level security
- Significant maintenance overhead with custom reports
- Reports and their outputs are stored within SailPoint
The Solution
Now 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: externalize it.
You would ideally create a read-only replica of your SailPoint database and offload all your reporting functionality to it. Then you set up 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. Better performance: SailPoint and reporting now run on separate systems, at both the application and database tiers, so both perform better. Your identity application focuses on identity management and governance, while the business intelligence tool 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. More 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, you can't accidentally corrupt SailPoint data.
You may ask: what if the database schema changes, while the API stays stable, and you have to rework the reports? That has not been our experience so far. SailPoint’s database schema has more or less remained similar to its previous releases, while the API has seen frequent improvements and deprecations. You can write custom queries across multiple tables, no longer constrained by the product’s API, however rich it is.
I must mention here that we have developed custom functionality in this area to parse SailPoint XML data and expose it in a tabular form so it can be easily queried and consumed by end users. It shows how far you can take this.
You can even take this further by pulling in data from other sources and correlating it with your SailPoint data to really make sense of your identity governance. With this you can derive performance, security, process gap and compliance implications that you would miss using SailPoint’s data alone.
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, it's just not possible. You will need to create custom reports. And even then, the report task definition cannot be modified in runtime. The best you can do is show an empty column in the output, which is not a great user experience.
The business intelligence tool we have provided to our clients to implement this system not only supports AD authentication and SAML SSO, but you can control access at data source, report, row, and column levels too, based on a user’s identity and AD group membership. This greatly simplifies and strengthens your data access security model.
4. Less maintenance overhead and faster development: SailPoint at its core is an identity governance tool, and it's great at that. Reporting within SailPoint, while rich, is not its core function. 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.
5. Happier end users, developers, and management: As mentioned, a core Business Intelligence tool can make creating reports, filtering data and interpreting your data so much easier, intuitive and rich. You get enhanced features also like runtime filtering, sorting, drill down, tree maps, etc. No more hours spent updating and rerunning reports.
And with happy end users, you get happy stakeholders and happy program owners. A win-win for all.
Identity Governance should provide Business and Security Intelligence
To summarize, externalizing your reporting from SailPoint to a business intelligence tool that reads from a read-only database delivers:
- Better Performance
- More Flexibility
- Stronger, More Granular Security
- Less Maintenance Overhead
- Fast Development Time
- Happy Customers
- Happy Program Owners
These benefits are not limited to SailPoint environments. Any identity governance environment can benefit from this solution.
Want to Try This?
We have built this for clients, including our own capability to parse SailPoint XML data into tables that business users can query. If your SailPoint reporting is slowing down your environment or tying up your developers, book a 30-minute call and we'll walk through what externalizing it would look like for you.