An authorization engine does not know your business
What fine-grained authorization demonstrations do not always show. A readable policy only becomes an operational control once the surrounding architecture knows, in time, where to find the business data and how to enforce the answer. This piece is about human identities — employees, agents, contractors, partners and external users known to the organisation.
Claire, a document and a rule that looks simple
Claire works in the legal department of a large organisation. Her identity is well managed. Netwrix Identity Manager knows her employer, her status, her department, her manager, her assignments, her entitlements and any temporary exceptions. Her account is created, provisioned and governed. She accesses a document platform through SSO and strong Authentication.
The organisation wants to enforce a rule that, spoken out loud, fits in a single sentence. Claire may consult documents attached to matters handled by her team. She may only download a document classified "Restricted" if she is explicitly named on the matter. On a sales slide, the rule looks immediate. A subject — Claire. A resource — the document. An action — read or download. A policy — permit or deny.
This is where we start asking questions. Where does the classification of that document live? In a Microsoft Purview sensitivity label, in a SharePoint property, in the document management system, in a business database, in the file name, in a Word document property? Where does the list of people named on the matter live? Does the application expose that information? How does the decision engine retrieve those attributes? How does the application tell the engine which document is being touched? Where is the deny going to be enforced in practice? Those questions are the actual project.
One scoping point before we go further. For many human accesses, PBAC and Fine-Grained Authorization are not required. A reliable lifecycle, governed entitlements, coherent roles and patterns, groups, access requests, recertification campaigns, strong Authentication and a few simple application controls will often be enough. Fine-Grained Authorization becomes truly useful when the decision depends on the specific resource, the requested action, a business relationship, a regulatory attribute or a context that cannot be reasonably materialised in advance.
Three decisions, three moments in time
Many conversations drift because three functions are conflated in the same slide. The first is Identity Governance. Netwrix Identity Manager can determine that Claire, as a lawyer attached to this department, must have an account and access to the document application. That decision rests on her identity, her lifecycle, her organisation and the attribution rules. It answers the question: should Claire be allowed to enter this application at all?
The second is Authentication. Ping Identity, Microsoft Entra ID or Keycloak verify that the person showing up is actually Claire. They handle SSO, MFA, federation, sessions, tokens, Identity Claims and part of the contextual controls. They answer the question: is the connected user really Claire, and under which authentication conditions?
The third is Authorization, and more precisely Fine-Grained Authorization when the decision drops to the level of a specific resource. Once Claire is inside the application, a much sharper decision sometimes has to be taken. Is she allowed to download this particular document? The answer depends on Claire, but also on the document, on the matter, on the action, on the classification, on the relationship between Claire and the matter, and sometimes on the regulatory context. This decision can be delegated to an engine such as Axiomatics — provided the information it needs is actually reachable at the moment the question is asked.
Seven statements we hear in demos, seven questions we ask
We are not here to discredit vendors. We simply describe the questions we ask during demonstrations, because these are the questions on which the programme depends. For each statement, we bring the conversation back to Claire and her document.
- 01
"Our platform does PBAC"
The demo shows a readable policy: a user may download a document if they belong to the right project and the document is not confidential. The interface is convincing. We ask one question. How does the platform know the classification of that Word document? The answer cannot be "through PBAC". PBAC evaluates information; it does not create it. Classification has to be retrieved from a sensitivity label, a SharePoint property, a document management system, a business database, an API or a document classification tool. That is the role of the Policy Information Point. A pure SaaS product does not magically walk the whole information system; it needs a hook to reach the data — an API, a connector, an event stream, an agent, a local component or a request-time payload. An engine that only receives Claire's attributes knows Claire. It does not yet know the document. A PBAC capability may be technically real and remain unusable for the business case as long as the Resource Attributes are not wired in.
- 02
"The whole decision is dynamic"
The demonstrator changes Claire's department in the test tenant. The policy immediately produces a different answer. We ask whether the business data really was updated in real time. A Runtime Decision can perfectly well be computed from information synchronised the night before. Take a concrete example. Claire leaves the project at 10 a.m. The project database is updated within seconds. The engine, however, uses a copy synchronised every night. Claire keeps being seen as a member of the project until the next batch. The policy is dynamic; the data is not. We systematically separate the moment the business data changes, the moment the engine receives it, the moment a cached decision is invalidated and the moment the application applies the new answer. "Real-time decision" does not necessarily mean "real-time data".
- 03
"Our authorization runs at runtime"
The word runtime is often used as a proof of modernity. We bring it back to a measurable case. Claire opens a page with ten matters, several documents per matter, view buttons, download buttons, a share function and an export function. The application may have to check several authorizations to render this single page. Suppose — purely as a reasoning example — that ten decisions are queried sequentially and each remote call adds 500 milliseconds; the page accumulates five seconds of wait for authorization alone. That figure is not a product benchmark; it is a test hypothesis. Even with parallel calls, the Latency of the slowest one remains visible and the platform still has to absorb the aggregate volume. We ask how many decisions are needed to render one page, whether a decision is taken per resource, per action or per screen, whether calls are sequential or parallel, what the median latency is, what the p95 and p99 look like, what happens under load, whether the engine is called from the browser, the API or the backend, and where it is physically hosted relative to the application. The word "runtime" gives neither the number of calls, nor their latency, nor their place in the user journey.
- 04
"Caching solves the latency question"
Caching can be an excellent answer. It also opens new questions. Suppose Claire was granted permission to download documents from a matter, and the answer is cached for fifteen minutes. At 10:05 a.m. she is removed from the matter. What happens to the cached decision? We ask where the cache lives — in the application, in a proxy, in the engine —, what its TTL is, whether it is keyed by user, resource and action, whether an attribute change immediately invalidates the decision, how Revocation is propagated, and how long Claire can retain an access after the change. There is no universal answer. For a low-stakes view button, a few minutes are acceptable. For a regulated operation, the same delay may be far too long. Caching trades latency against the fact that a decision remains valid for some time. That time has to be chosen, not hidden — and Cache Invalidation has to be described, not assumed.
- 05
"The service is highly available"
We ask what happens when the authorization engine is unreachable. Two behaviours are possible. In Fail Closed, the application denies the action. Security stays strict; Claire may find herself unable to work. In Fail Open, the application allows the action or reuses a previous decision. The service stays available; the control is temporarily weakened. Bring Claire back into the picture. If the engine becomes unavailable, can she still read a document, edit a contract, download a classified file, share a document with a third party? The answer does not have to be the same for every action. An architecture may allow the reading of already-accessible material while blocking downloads and shares. We ask what the default behaviour is, whether it may vary per action, who validated that choice, how unavailability is detected, how decisions taken in degraded mode are logged, and how the system returns to normal. High availability of the service does not answer the question of what the application does when no decision arrives.
- 06
"Policies are centralised"
Centralising policy authoring and administration brings real consistency. It does not mean that every decision or every control is physically centralised. We distinguish four familiar points: the Policy Administration Point, where policies are written; the Policy Decision Point, where decisions are computed; the Policy Information Point, which provides the information needed; the Policy Enforcement Point, which applies the answer. Policies may be administered in a SaaS service. The decision engine may be remote or embedded. The enforcement point may sit inside the application, in an API Gateway, in a proxy, in a backend service or in an integrated component on the client side. We ask to see this architecture, drawn on paper, for Claire's case. Centralised policies do not mean that data, decision and enforcement live in the same place.
- 07
"Integration is code-free"
The interface sometimes allows a policy to be written without code. That does not remove application-side integration. To control a download, the application must at least send Claire's identity, the document identifier, the requested action and the useful context; it must then enforce the answer. If a legacy application offers no extension point, no compatible proxy and no usable API, the elegance of the policy editor is not going to be enough. We ask how the action is intercepted, who builds the authorization request, how the resource is identified, where the integration code sits, who maintains it, what has to change inside the application, and whether that integration is truly covered by the product standard. "Code-free" may describe how a policy is written without describing how the application is wired in.
None of these questions is meant to trap the vendor. They simply describe what will have to be designed, wired, maintained and audited once the demo is over.
The Ariovis test and the role of each component
A prospect does not naturally ask "show us your Policy Information Point". They express a business need: a lawyer must not be able to download a confidential document outside the matters they own. We turn that need into a demo scenario and ask the vendor to walk the whole chain — Claire's identity, the attributes describing her, the document in question, the source of its classification, the link between Claire and the matter, the policy, the request sent to the engine, the answer received, the response time, the actual enforcement of the deny, the audit trail produced, and the behaviour when the business source or the engine is unavailable. We then ask them to change one piece of data — remove Claire from the matter, change the classification, temporarily revoke project access — and we watch how long it takes for the new situation to be actually enforced. A PBAC demo must not only show a policy that answers "permit" or "deny". It must show the full path from the data to the control.
- Netwrix Identity Manager
- Netwrix Identity Manager governs human identity over time. It consolidates data, drives the lifecycle, applies attribution rules, handles access requests, formalises roles and patterns, provisions, recertifies, surfaces drifts and stores audit evidence. It can determine that Claire belongs to the legal department and must have access to the document application. It is not designed to open every document at the moment Claire clicks "Download". That is neither its mission nor its cadence.
- Ping Identity, Microsoft Entra ID or Keycloak
- These Access Management platforms handle, depending on the setup, Authentication, SSO, MFA, federation, sessions, tokens and Identity Claims. They establish that the connected person is indeed Claire and pass along part of her identity and connection context. A claim carrying "legal department" does not, on its own, provide the document classification, the matter owner, the requested action or the relationship between Claire and the resource. Those are other pieces of data, held by other sources.
- Axiomatics
- Axiomatics can carry the fine-grained authorization decision. It evaluates a policy — RBAC, ABAC or PBAC — against information about Claire, the resource, the action and the context. The relevance of the answer depends on the quality of the information received, its freshness, the Latency of its retrieval and the integration with the Policy Enforcement Point. The policy engine replaces neither the business sources nor the application. It is a central component of the chain, not the whole chain.
- The business application
- The application often knows what the other components ignore: the object being touched, the state of the matter, the exact action, the business relationships, and where the deny actually has to be enforced. It is not a passive target of authorization; it is a full part of the mechanism. A successful fine-grained authorization architecture acknowledges that contribution, plans an explicit enforcement point inside the application, and does not expect an external component to guess what only the application code knows.
- The representative test
- We refuse to conclude on a single isolated decision shown in the demo. We ask for a test representing a real page or transaction, at the volumes and Data Classifications expected in production. That is the only way to measure perceived latency, load on the engine, effective freshness of the data and behaviour under degradation. A capability matrix can state that everything is covered; only a technical demonstration proves that the pieces actually work together.
A simple position, two shortcuts we refuse to take
We do not try to build the "Rolls-Royce" of IAM, and we do not recommend multiplying solutions without necessity. For many human accesses, a combination of Identity Governance, a directory, an Access Management platform and the existing application controls is enough. A specialised fine-grained authorization component becomes relevant when the use cases really require it — decisions that depend on the resource, on the context, on a business relationship or on a regulated attribute.
Pragmatism then means refusing two shortcuts. The first is to assume that a single product spontaneously knows every piece of data in the information system; it only knows what the architecture brings to it. The second is to assume that a policy displayed in a nice editor is already an operational control; it only becomes one when the business data, the decision and the enforcement point meet, on time, on the actual resource.
We do not turn our back on ambitious promises. We simply ask to see where the data is, how long the decision takes and how its result is enforced. Those three questions turn a demonstration into a project.
Back to Claire, and to the chain that protects her
For human identities, PBAC is not needed everywhere. When it is needed, it is not a standalone feature. It is a chain made of a governed identity, a reliable Authentication, an identifiable resource, an accessible business attribute, a policy, a decision engine, an enforcement point, a caching and revocation strategy, a degraded mode and an audit trail.
Back to Claire one last time. Netwrix Identity Manager governs her identity and her access to the application. The Access Management platform verifies who she is and passes her claims. The application identifies the document and the requested action. The business source provides the classification and her relationship to the matter. The authorization engine evaluates the policy. The enforcement point applies the answer. The audit trail lets us later explain the decision. No component carries the whole chain on its own.
When we assess a fine-grained authorization promise, we do not simply ask whether the product can answer "permit" or "deny". We check what it really knows about the resource, how long it takes to decide, and what happens when the answer does not arrive.