Your business team did not deploy Keycloak to rebuild your SSO
It needed to decide what the user was allowed to do after signing in. Field notes from a senior Ariovis IAM architect on the Keycloaks, OAuth servers and local entitlement stores that appear next to enterprise SSO — not to condemn them, but to understand the authorization need they reveal.
The architecture meeting that was not about authentication
In an architecture meeting, the IAM team discovers a Keycloak deployed by a product team. The first question, almost a reflex, could have been: "Who authorised you to install a second identity provider?" The Ariovis consultant asks something else: "What decision did your application need to make?"
The team explains that the central SSO already authenticates users correctly; that the directory provides their identity and organisation; that the application also needs to know their products, departments or perimeters; that this information does not exist in the LDAP; and that no central service allowed it to be used in a policy. Keycloak was chosen to enrich the token and deliver the application on time.
The consultant first recognises the legitimacy of the need. He then examines the consequences: token size and freshness, data duplication, local rules, revocation, operations, audit and the possible multiplication of the same architecture. The discussion does not seek to pit the business against IAM. It seeks to build a better shared response.
The business had solved its delivery problem. Our role was now to help it turn that local solution into a sustainably secure capability.
SSO tells you who; the application still asks what
A company works because its business units sell, produce, care, transport, advise, finance, build, administer and serve their customers and users. Cybersecurity and IAM are not an end in themselves: they exist to let those activities operate at a controlled level of risk. This is what Security Meets Business means at Ariovis.
When a business team stands up its own Keycloak, enriches a token or codes a local entitlement logic, our first reaction is therefore not to say that they failed to follow the architecture. We first ask: which business operation did they need to make possible, and which answer did the central IAM setup fail to give them? Security Meets Business means we do not secure an architecture against the business. Together with the business, we build an architecture that lets it act securely.
The central SSO establishes, often very well, a set of solid facts: who the person is, their employer, their organisation, their email, a few groups, a few global roles, the authentication level and the session context. Token audience and scopes give the application stable anchors. That is enough to open a session, apply a general access policy and pass along a few useful identity claims.
The application often needs a sharper decision. Can this person perform this specific action on this specific business object? Answering that requires the products she manages, the departments she is assigned to, the stores where she can act, the customers in her portfolio, the contracts she owns, the amounts she can approve, the classification of the data she reads, the project a resource is tied to, the purpose of the action. These are not identity attributes. They belong to the business.
Introducing that distinction changes the tone of the workshop. SSO usually tells us who is showing up. The application is still asking what that person can do with its own business objects. As long as this sentence is not shared, the IAM team and the product team are discussing two different problems while believing they are discussing the same one.
We then have to resist a second, symmetrical temptation: framing Shadow IAM as the sole fault of the application team. When a business unit works around the central setup, several causes almost always coexist. The IAM service does not respond quickly enough. The service catalogue only covers authentication. The role model is too coarse for the decision that is needed. Business data is not accessible to the decision engine. No fine-grained authorization mechanism is offered. The IAM team was not involved early enough. The business does not know who to bring its need to. And the application still has to meet a delivery date.
The workaround does create debt, duplication, audit difficulty and additional surface to maintain. But it also reveals that the need was real. Shadow IAM is rarely a sign that a business team does not want security. It is more often a sign that it did not find, in the existing setup, a security posture compatible with its activity. That does not excuse every local architecture — some have to be corrected. The correction simply starts with understanding the need, not with authoritatively removing the component.
Security must not become a parallel administration of the business
To avoid local Keycloaks, an organisation may be tempted to push everything into the central directory: every product, every department, every store, every contract, every customer, every delegation, every classification and every approval limit. This looks like it gives IAM back control. In practice it turns the IAM team into the administrator of data it does not own and cannot maintain properly.
Business systems of record must stay with the people who understand their meaning, their lifecycle, their quality, how often they change and their confidentiality rules. The role of IAM is to let an authorization policy consume that information in a controlled way, without moving or rewriting it on behalf of the business.
Security Meets Business does not mean absorbing the business into IAM. It means enabling IAM and the business to make a decision together without confusing their responsibilities.
Ariovis's role in this conversation
Ariovis acts as a translator between several worlds. With the business, we seek to understand the action to be performed, the resource involved, the consequences of a wrong decision, legitimate exceptions, the frequency of changes, delegation needs and deadline requirements. We do not ask business teams to phrase their need in IAM vocabulary; we ask them to describe the operation they want to enable.
With the IAM team, we identify what belongs to identity, IGA, authentication, the token, durable roles, lifecycle and access review. We clarify what the central setup can already provide and what naturally falls outside its scope.
With architects and developers, we determine where the decision should be made, what data is needed, where to place the Policy Enforcement Point, how to query the systems of record, how to manage latency, how to trace the decision and how to handle the unavailability of a source.
With security, we verify that the rule cannot be bypassed, that exposed data remains limited, that rights are revocable, that decisions are auditable and that the architecture remains operable.
Our value is not to ask the business to speak the language of IAM. It is to translate its need into an architecture that security, applications and operations can actually carry.
Fine-grained authorization as a service to the business
Fine-grained authorization and PBAC are not a sophistication imposed by architects. They become relevant when they let a business rule be expressed directly: "This manager can change the price of this product because it belongs to her department, in the store she runs, during the period her delegation is active and within the amount she has been granted." That rule is closer to the real need than adding hundreds of groups, copying the catalogue into LDAP, putting the entire product list in a token, or coding a different rule in every application.
IGA keeps governing durable roles and delegations. SSO keeps authenticating users and issuing tokens. Business systems of record keep describing products, stores and contracts. The PBAC engine assembles this information when the action is requested, without moving or rewriting it.
Fine-grained authorization is not there to make the architecture more elegant. It is there to let the business express its rule without having to rebuild an IAM platform itself.
What Shadow IAM actually carries when you look closely
The forms we describe below are the ones we meet in the field. Each is a local answer to a real need. Taken in isolation, none of them deserves to be condemned. Together, they raise governance and cost questions as soon as they multiply across the application landscape.
- 01
A Keycloak that federates more than it authenticates
The application team deploys a dedicated Keycloak realm. The central SSO authenticates the user. Keycloak acts as an Identity Broker, receives the identity and enriches the token with application claims: store_ids, department_ids, product_categories, approval_limit, business_roles, legal_entities. This is a perfectly legitimate use of Protocol Mappers and token enrichment. Ping Identity, Okta or Entra ID can do the same. The vendor is not the question. The question is why the team felt it had to own its own computation layer.
- 02
A token that becomes a portable data warehouse
One more use case arrives, then another. The token grows. It no longer carries only an identity, an audience and a few scopes. It carries a detailed representation of the relationship between the person and the business resources. Token Bloat shows up in proxies, logs and sometimes browsers. Information useful to one API does not necessarily need to reach every application receiving the same token. Freshness becomes tricky: a product moved to a different department, a delegation revoked, an amount revised — tokens already issued are not silently rewritten. Past a certain point, the token no longer carries an authorization. It carries a temporary snapshot of the business model needed to recompute one.
- 03
Rules coded inside the application
Not every team deploys Keycloak. Some receive the identity and rebuild the decision themselves. The application calls the directory, the CRM, the ERP, a store master, a delegation store, a classification service. It then codes a rule such as: allow the price change if the user is a manager, the product belongs to their department, the store falls within their scope and the discount stays below their ceiling. The rule works. But every application ends up developing its own engine, its own connectors, its own cache, its own interpretation. The enterprise policy becomes the sum of implementations that never talk to each other.
- 04
A local entitlement table that quietly becomes a mini IGA
Another team creates a local table: a user, an application, a resource, a role, a start date, an end date. The intent is modest. Then joiners have to be handled, movers, leavers, delegations, requests, approvals, revocations, audits, orphan accounts, legacy rights. Shadow IAM often appears when the application team starts by adding a single claim and ends up running a full lifecycle it never planned to operate. What was meant to be a table has become an ungoverned Identity Governance component.
- 05
A directory asked to become the digital twin of the enterprise
Faced with these difficulties, a tempting shortcut appears: expand the LDAP or Active Directory content. Add stores, departments, product categories, contracts, customer portfolios, delegations. An identity directory is not the digital twin of the entire enterprise. We do not make authorization simpler by turning LDAP into a large business-data sink. We only move complexity into a repository that was never designed to hold it, with sync cycles, naming logics and exposure patterns unsuited to fast-changing Business Data.
- 06
Costs that are diffuse, hard to price, easy to observe
We do not invent counts of instances or budgets. We observe concrete lines: infrastructure, high availability, upgrades, patches, monitoring, backups, secrets, certificates, pipelines, expertise, documentation, support, recovery procedures, version migrations. Add the less visible costs: understanding the rules, maintaining protocol mappers, correcting divergences, reviewing claims, investigating decisions, reconciling with sources, auditing, explaining denials. The problem is not the cost of one isolated instance. It comes from the number of places where the organisation has to understand, correct and prove the same policy.
- 07
Governance that stops at the login screen
The recurring point is not technical. Business teams do not always bypass governance because they reject it. Sometimes they bypass it because governance stopped at the login screen. The IAM service catalogue offers authentication, federation, MFA, a few global roles. It does not describe how to express a fine-grained authorization need, how to plug in a business source, how to obtain a shared Policy Decision Point, how to place a Policy Enforcement Point inside an existing API. The application team answers with what it has. It has Keycloak and it has code.
Do not hold it against the business that it had a use case. If it went around the IAM service, first check whether the service was actually offering an answer. Swapping the vendor of the token server does not solve an authorization need that has never been handled as an enterprise service.
Four responsibilities to separate, without pitting them against each other
Shadow IAM rarely dissolves through a removal decision. It dissolves when each actor recovers its own responsibility and stops carrying someone else's. Here are the four domains to separate clearly, and the components Ariovis works with day to day.
- Identity Governance
- IGA governs identity over time: existence, lifecycle, structural roles, entitlements, requests, approvals, access reviews, revocations, audit evidence. Netwrix Identity Manager plays that part at several of our clients. This is where durable Entitlements and governed roles belong — not inside a protocol mapper.
- Access Management and federation
- The Access Management platform authenticates, federates, manages sessions, enforces MFA, issues tokens, passes useful Identity Claims and manages audiences and scopes. Ping Identity is our reference technology partner in this area. We also work on Microsoft Entra ID, Okta or Keycloak when the context calls for it, without pushing a single vendor.
- Business systems of record
- The product catalogue, the store master, the customer base, the contract system, the document classification, the data catalogue, project management and operational delegations remain owners of their own data. They do not need to be copied into LDAP or packaged inside a token. They expose that data through APIs that can be queried at decision time, as Policy Information Points.
- Fine-Grained Authorization — PBAC
- The authorization layer decides, at the moment of the action, which subject is acting, which action is requested, on which resource, in which context, under which policy. A PBAC architecture typically involves a Policy Decision Point to evaluate the policy, several Policy Information Points to provide attributes, and a Policy Enforcement Point inside the application, the API or the API Gateway to apply the decision. Our partnership with Axiomatics lets us address the problem Shadow IAM reveals: not merely issuing a better token, but building an authorization service that applications can genuinely consume.
- The business application itself
- The application knows things the other components do not: the exact object touched, the precise action, the immediate context, the place where the deny has to be enforced. It is not a passive target of authorization. It is one of its actors. A successful architecture plans an explicit enforcement point on the application side, and does not expect an external component to guess what only the application code knows.
- The role of the internal IAM programme
- The goal of an IAM programme is not to own every rule. It is to offer a frame in which a business rule can be expressed, enforced and maintained without rebuilding a fresh identity chain. Depending on the need, the right answer may be a standard claim, an IGA-governed role, an OAuth scope, an integration with a system of record, an enrichment service, a PBAC policy, a shared PDP, a PEP pattern, a delegation architecture, or simply a recommendation to the application team.
A minimal token is not an impoverished one
The debate is not about stripping every claim out of an access token. A token can legitimately carry the subject, the issuer, the audience, the validity period, scopes, some roles, the authentication level and a few stable attributes needed by the resource. A good token gives an API what it needs to recognise the capability being presented. It does not have to contain every piece of data required to recompute every business decision. The ID token and the access token do not serve the same purpose either: the first informs the client about how the user authenticated, the second is aimed at the protected resource. Applications should not be encouraged to use the ID token indistinctly as a universal entitlement matrix.
Token enrichment remains a good answer in a very concrete set of cases: when the information is limited, relatively stable, not particularly sensitive, its validity is compatible with the token lifetime, and the rule concerns a single application. A token stating that an employee is attached to store 013 with a global store_manager role often suffices to open a store management workspace. Not every claim is Shadow IAM. The problem starts when the token becomes the only place able to explain a complex business policy.
Fine-Grained Authorization becomes relevant when the decision depends on the specific resource, the specific action, a dynamic context, several systems of record, data that changes faster than the token, a temporary delegation, an amount, a classification, a purpose, or when revocation must be rapidly effective and proof of decision is expected at audit time. We do not swap a protocol mapper for a PBAC engine to modernise the diagram. We do it when the rule no longer fits cleanly inside a token's lifecycle.
Does that mean the local Keycloak has to go? Never automatically. It may keep a legitimate role as identity broker, compatibility facade for an application, local authorization server, protocol translation layer, migration waypoint, or component owned by an autonomous product. The objective may simply be, over time, to move business data out of its claims, complex rules out of its protocol mappers, shared decisions towards a PDP, role governance towards IGA, and authentication towards the central service. Rationalising Shadow IAM does not mean removing every Keycloak. It means making explicit the responsibility each of them exercises.
Back to the architecture meeting, with the right questions
This way of reopening the conversation is a direct expression of the belief that structures our work: Security Meets Business. The question we put to the application team is not to justify their architecture. It is to name the business operation they needed to make possible. That operation — not the IAM org chart — is what shapes the target architecture.
When a local Keycloak surfaces, we do not start by counting servers. We start by inventorying the decisions they make. Which identity does it receive from the central SSO? Does it actually authenticate the user or does it act as broker? Which claims does it add? Which sources does it use, who owns them, is the data copied or queried, how fresh is it? What is the token lifetime, and what happens when an entitlement is revoked mid-session? Where is the rule documented, who can modify it, how is it tested, how is it audited, does an access review exist? Do other applications quietly implement the same rule?
Shadow IAM is not only a debt to erase. It is a diagnostic tool. It reveals needs that were not visible, business rules missing from governance, essential systems of record, applications that require dynamic decisions, limits in the IAM service catalogue, and teams able to articulate precise use cases. Shadow IAM is sometimes the best map available of the authorization needs the central programme never collected.
Ariovis defends neither absolute centralisation nor total application autonomy. A fully centralised platform can become slow to evolve, distant from business data, dependent on a single team. A fully local architecture produces duplication, drifting rules, run costs, audit difficulties and fragmented governance. We look for a clear split of responsibilities: central identity governance, coherent authentication and federation, business ownership of the data, shared authorization policies when they need to be shared, local enforcement of the decision as close as possible to the resource. Centralising authorization does not mean centralising every dataset or every team. It means making the policy coherent and the decision consumable.
When your business teams deploy Keycloak behind your SSO, do not start by asking why they rebuilt IAM. Ask them which authorization decision they could not obtain any other way. Their local architecture may not be the target design, but it shows you very precisely which service is missing from your IAM programme.
Conclusion
The IAM team had discovered an additional Keycloak and initially thought they would have to rationalise a duplication of the SSO. The exchange with the business revealed something else. The central SSO authenticated users correctly. The directory provided the information needed to recognise them. But the application had to make decisions about products, departments, stores, contracts, delegations, resources that the central IAM setup did not know.
The product team had therefore built the response it could deliver. That response had limits: growing token enrichment, dependencies on several systems of record, local rules, revocation difficulty, new infrastructure to operate.
Ariovis does not start by blaming the business for the workaround. We recognise that the company works because this business knows how to sell, manage its products, serve its customers, take operational decisions. Our role is to secure that capability, not to prevent it.
We then help the organisation distinguish what should stay in the directory, what should be governed in IGA, what can be carried in the token, what belongs to business systems of record, what requires a PBAC decision at runtime. The local Keycloak can be kept, simplified, repositioned or gradually replaced according to its real role. The objective is not to make the central architecture win against the local architecture. The objective is for the business to finally have an authorization service suited to its need, governed, secure, maintainable, operable.
Security Meets Business begins with a form of humility: recognising that security is not what keeps the company alive, but that it must let those who do keep it alive exercise their trade with confidence. When business units work around IAM, our first responsibility is not to defend our architecture. It is to understand what they were missing and to build a safer response with them.