Introduction
Ever wonder how SailPoint IdentityIQ knows who you are, what you should access, and what’s considered “normal” behavior?
It all starts with something called an authoritative application — and if you’re working in IAM, especially with SailPoint, understanding this concept is critical. Think of it as your source of truth. Without it, your entire identity ecosystem is just guessing.
In this article, I’ll explain what authoritative applications are, how they help build identity cubes in IIQ, and share real-life examples that make this a lot less abstract than it sounds.
What exactly is an authoritative application?
Let’s make it simple.
An authoritative application is any system that SailPoint trusts to provide the real identity data for a person. It’s not about access — it’s about who the person is.
Imagine HR is the system that says, “This is Ahmed. He’s a full-time employee in the IT department, working out of Montreal.” That’s authoritative. On the other hand, Active Directory might say, “Ahmed has an account here with access to five groups.” That’s useful, but it’s not the core identity data.
Authoritative applications feed SailPoint with things like:
- Employee name, title, and department
- Employment status (active, inactive, contractor, etc.)
- Manager relationships
- Location and business unit
If you’re not pulling this from a reliable source, your identity cube will be missing critical context — and you’ll end up approving access for people who might not even work there anymore. (Yes, it happens. A lot.)
How does IIQ use these sources to build the identity cube?
When data is pulled from an authoritative application, SailPoint creates an identity cube for each individual.
Think of an identity cube like a digital profile — not just who someone is, but what they have access to, what policies they fall under, and what risks they represent. It includes:
- Attributes from authoritative sources (name, title, location)
- Linked accounts from other apps (AD, ServiceNow, etc.)
- Entitlements and group memberships
- Access history
- Policy violations or exceptions
This cube becomes the central object SailPoint uses to make decisions — like access reviews, certifications, provisioning, and risk scoring.
So if your authoritative data is clean, consistent, and up-to-date? Everything works better. If it’s a mess? Welcome to chaos — and probably some audit nightmares.
Real-life example: When HR meets Active Directory
Let’s say you’re integrating SailPoint at a mid-sized financial company.
Step one: you pull employee data from the HR system (like Workday). This becomes your authoritative application. SailPoint reads it, creates identity cubes, and assigns a unique identity to each employee.
Now you connect Active Directory. AD is not authoritative in this case — it just contains accounts and groups. SailPoint links AD accounts to the identity cubes based on things like email or employee ID.
Result? You can now see who someone is (from HR) and what they have access to (from AD), all in one place. No more spreadsheet gymnastics.
But here’s the kicker — let’s say an employee leaves the company. HR marks them as “terminated.” Because HR is authoritative, SailPoint disables or removes their accounts everywhere they had access. Automatically.
That’s the power of using authoritative sources properly. It’s not just cleaner — it’s smarter, safer, and way easier to explain to your compliance officer.
Why this matters as the IAM market explodes
With the IAM market expected to hit over $24 billion by the end of 2025, everyone’s moving fast. But speed without structure leads to mistakes — especially in identity data.
Authoritative applications give you that structure. They let you build identity cubes that actually reflect your workforce, so you can manage access, compliance, and risk with confidence.
And with more companies using multiple authoritative apps (like combining HR and contractor databases), understanding how to prioritize and merge those sources is a must-have skill for any IAM developer or architect.
Conclusion
So, next time someone says “We’ll just use Active Directory as the source of truth,” pause and ask: do you really want your access governance strategy built on a system that doesn’t even know if the person is still employed?
Authoritative applications are the cornerstone of SailPoint IdentityIQ — and they’re what make identity cubes accurate, useful, and actionable.
If you’re working in IAM, get to know your authoritative sources. Validate them. Prioritize them. And make sure your identity cubes aren’t just technically correct — but contextually right.
Have you dealt with messy identity data before? Or maybe you’ve had to untangle an Active Directory that was treated like HR? I’d love to hear how your team approached it.
Let’s talk in the comments.