> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/access/where-authentication-lives.md). # Where authentication should live Decide who verifies the credential when a user signs in — OpenIAM itself, an existing federation service such as ADFS, or the directory itself — and why delegating each sign-in back to Active Director ## What this is, and when you need it When a user signs in, something has to check the credential. This page decides what: OpenIAM against its own credential store, another identity provider that OpenIAM trusts, or the directory itself, asked afresh on every sign-in. The question is asked in almost exactly these words in every first design conversation — *"does the authentication request go to my Active Directory, or does OpenIAM authenticate me?"* — and the answer shapes the password design, the availability design and the MFA design that follow. You need this page before you size anything, because two of the options put a third-party system on the interactive sign-in path and one of them does not. ## The decision | Option | How it works | What it costs | What it buys | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **OpenIAM verifies the credential** | OpenIAM holds a credential for the identity and checks it directly | OpenIAM must hold a credential, which is what makes password strategy the next decision | The shortest sign-in path, full control of policy, factors and lockout, and no dependency on a directory being reachable | | **Offload to an existing federation service** — ADFS, Entra ID, another SAML identity provider | OpenIAM acts as a service provider; the other provider authenticates and returns an assertion | A federation trust to maintain, and the factor policy moves to the other provider | Clean, efficient, no credential in OpenIAM for that population, and reuse of an MFA investment already made | | **Desktop single sign-on with Kerberos** | The domain-joined workstation presents a ticket at the proxy tier; OpenIAM issues a session for the matching identity | Service principals, a keytab and the domain team's lead time; only works for domain-joined devices on the network | No login page at all for the population it covers, using Active Directory the way Active Directory is meant to be used | | **Delegate each sign-in back to the directory** | OpenIAM asks the directory, through its connector, to verify the credential on every sign-in | A connector round trip per sign-in, and a hard dependency on the directory for interactive access | Nothing is stored in OpenIAM. Defensible for a small estate; **not recommended at scale** | ## The house position **Do not delegate authentication back to Active Directory where a federation service is not present.** It is slow, it does not scale to six figures of users, and Microsoft's own direction of travel has moved away from directory bind as an authentication mechanism and towards federation. Designing on it now is designing on something that will be argued about at every subsequent architecture review. **Where ADFS is enabled on the domains, offloading credential verification to it is clean and efficient**, and it is the recommendation. That is why "is ADFS enabled?" is the first question to ask back, before answering anything else about the authentication design. ## Why delegating back to the directory does not scale It is worth being specific, because "it is slow" is not an argument that survives a design review. OpenIAM does ship the capability. An authentication provider can be bound to a managed system so that the credential check is performed by that system rather than by OpenIAM, and a directory-backed provider of exactly that kind ships as an example. The mechanism is the same one used for provisioning: OpenIAM issues a login operation to the managed system's connector. That is the problem. **A delegated sign-in is a full connector round trip over the message broker**, on the interactive path, per sign-in. The connector is a separate process attached to the broker and shared with every other operation targeting that system — provisioning, reconciliation, synchronization. So interactive sign-in throughput becomes bounded by connector throughput, and it competes with a reconciliation run over a hundred thousand accounts for the same capacity. OpenIAM's own sign-in path is already a chain of blocking service-to-service calls; delegation adds a further hop out of the platform and back, and there is nothing on that path that can be cached, because the whole point is to ask the directory afresh. Three operational consequences follow, and all three are worth stating in a design document: **The directory becomes a hard dependency for interactive access.** If it is unreachable, nobody signs in. There is no credential in OpenIAM to fall back to, by design, and no cached verification. **Sign-in latency inherits the directory's worst case**, including the network path to whichever domain controller the connector reaches, across forests and across sites. **Every additional forest multiplies the problem.** Five forests means five managed systems, five connectors, and a sign-in design whose availability is the product of five availabilities. None of this makes delegation wrong for a small estate on one domain with a nearby directory. It makes it the wrong basis for a hundred-thousand-user, multi-forest design. ## Offloading to ADFS, precisely Where a federation service exists, OpenIAM acts as a **SAML service provider**: the user is sent to the existing identity provider, authenticates there under that provider's policy, and returns with an assertion that OpenIAM validates and turns into a session. Four properties of that path belong in the design rather than in the runbook. **The protocol is SAML 2.0.** OpenIAM does not implement WS-Federation. An ADFS estate that currently federates internal applications over WS-Fed will need SAML 2.0 relying-party trusts for this, which is ordinary ADFS work but is worth naming, because it is occasionally assumed. **Correlation is against a nominated managed system's principals**, with a resolver script available where the standard mapping cannot produce the value. This is the mechanism that lets the two estates use different identifiers — see [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) and Part 2, *Choosing the enterprise unique identifier*. **The user must already exist, and must be entitled.** Two separate conditions: OpenIAM must resolve the assertion to an existing user, *and* that user must be entitled to the provider's resource. A user who resolves but is not entitled is refused. Just-in-time creation is available but is off unless configured — which is the correct default for a workforce estate, and the concrete form of the position that lifecycle comes before single sign-on. **The factor policy moves.** If ADFS authenticates, ADFS's MFA policy is the one that applies at sign-in. OpenIAM can still demand a stronger factor on a specific path — step-up is attached to the URL, not to the provider — but the baseline is no longer yours. Where that is unacceptable for a subset of applications, say so in the design and put the step-up requirement on those URLs deliberately. ## The mixed estate An organization with several forests very often has ADFS on some and not on others. That is a supported shape and it does not need to be resolved before the programme starts, but it does need to be stated: authentication is chosen per traffic path, not once for the platform. A content provider or a specific URL can carry its own authentication rule, so one estate can offload one population to a federation service and authenticate another natively. What it must not become is a per-domain patchwork with no target state. Write down which populations authenticate where today and which of those arrangements is intended to persist, because the answer drives the password design in the next page: a population OpenIAM authenticates needs a credential in OpenIAM, and a population ADFS authenticates does not. ## Keep a way in that does not depend on any of this Whichever option is chosen, one break-glass route must survive it. An authentication design that offloads everything to an external provider locks out every administrator on the day the trust breaks or the certificate expires, including the administrator who would fix it. Reserve a small number of accounts that authenticate natively, on a path that does not traverse the federation trust, and test them on a schedule rather than assuming them. The Administration Guide's *Change configuration safely* makes the same point about the operational blast radius; here it is an architecture requirement, because it has to exist in the design before it can exist in the deployment. ## What we recommend **Where a federation service is present, offload to it.** It is efficient, it reuses an investment already made, it removes a credential from your scope, and it is the answer that survives scrutiny. **Where no federation service is present, authenticate at OpenIAM.** Hold the credential, own the policy, and use password synchronization to keep directory accounts usable — which is the subject of [Password strategy](/solution-architecture/access/password-strategy.md). **Add desktop single sign-on wherever workstations are domain-joined.** It is the best of both: Active Directory really is the authentication authority, but it authenticates the way it is designed to — a ticket the user already holds, not a bind performed on their behalf. The lead time is the domain team's, so start that conversation early. **Do not delegate sign-in back to the directory at scale.** The threshold is not a precise number of users; it is whether interactive access can tolerate a per-sign-in round trip to a directory through a shared connector, and whether the directory can be a hard dependency for signing in at all. In a six-figure, multi-forest estate the answer is no. **Decide per population, not per platform**, and write down what the target state is even when the interim state is mixed. The circumstance that changes this advice is a small single-domain estate with a directory in the same data centre and no federation service, where delegation is simple and the numbers are undemanding. Even there, prefer desktop single sign-on for the domain-joined population. ## What OpenIAM does not do here * **There is no WS-Federation support.** Inbound and outbound federation are SAML 2.0 and OAuth 2.0 / OpenID Connect. An ADFS integration is a SAML 2.0 relying-party trust. * **There is no RADIUS and no CAS.** Network devices and applications that speak only those protocols are not directly integrable. * **There is no cached or offline credential verification for delegated authentication.** If the managed system is unreachable, sign-in for that provider fails; nothing falls back. * **Delegated authentication is not free of the connector.** It uses the same connector and the same message-broker path as provisioning, and competes with it for capacity. * **Just-in-time creation from an inbound assertion is off unless configured**, and an unknown user is refused rather than created. * **OpenIAM does not control the factor policy of a provider it offloads to.** Step-up on a specific URL is available; overriding another provider's baseline is not. ## Related * [Password strategy](/solution-architecture/access/password-strategy.md) — the question that follows immediately: how would OpenIAM know the password? * [Entry points and the user's experience](/solution-architecture/access/entry-points.md) — where the user starts, once you know who authenticates them. * *The authentication model* and *Authentication providers and MFA* in the Administration Guide — the objects that implement this decision. * *OpenIAM as a SAML service provider* in the Administration Guide — the offload path, configured. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/access/where-authentication-lives.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.