> 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.md). # Authentication and access The decisions that settle how people prove who they are and how they reach applications — where authentication lives, what happens to passwords, how each application is integrated, and where a user st ## What this is, and when you need it Part 3 answers the four questions a customer architect asks in the first hour: **when I sign in, who checks my credential?** **How does OpenIAM know my password?** **What happens to the application that only has a login form?** And **do I have to start at your portal, or can I keep my bookmarks?** They are separable decisions, and OpenIAM supports more than one defensible answer to each. What they have in common is that all four are cheaper to settle now than after the first twenty applications are integrated, and all four depend on Part 2 having been settled first. That dependency is worth stating before anything else on this page. **Identity lifecycle and governance come before single sign-on.** A person must be known in OpenIAM and known in the target application before single sign-on can work at all — federation asserts an identity, it does not conjure one. A programme that starts with SSO because it is the visible win spends the following year discovering that its correlation key was wrong. ## The decisions in this part | Decision | Where it is made | What it turns on | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Who verifies the credential — OpenIAM, an existing federation service, or the directory itself | [Where authentication should live](/solution-architecture/access/where-authentication-lives.md) | Whether ADFS is enabled on the domains, and how many users have to sign in per hour | | Whether passwords are synchronized, federated, or both — and for which accounts | [Password strategy](/solution-architecture/access/password-strategy.md) | Whether accounts still need a local credential, and whether password changes originate in the directory | | How each application is integrated — protocol, gateway, form fill, or not at all | [Choosing an SSO approach per application](/solution-architecture/access/sso-approach-per-application.md) | What the application actually supports, which is a per-application answer and not a programme-wide one | | Where a user starts, and whether their bookmarks keep working | [Entry points and the user's experience](/solution-architecture/access/entry-points.md) | Whether the design is willing to work the way users already work | A fifth decision — **how strong the authentication has to be**, and when it should be stronger — is a policy design rather than an architecture one, and the Administration Guide owns it in *Authentication providers and MFA*, *Step-up authentication* and *Adaptive authentication*. What Part 3 contributes is where the decision is *made*: if credential verification is offloaded to another identity provider, the factor policy is largely that provider's, not yours. ## The first question to answer Before any of the four, establish one fact about the estate: **is ADFS, or an equivalent federation service, enabled on the domains?** It is the question to ask back before answering anything else, because it changes the shape of the whole authentication design. Where a federation service is present, offloading credential verification to it is clean, well-understood and costs you nothing operationally. Where it is absent, the tempting alternative — delegating each sign-in back to Active Directory — is the option this guide argues against, and the reasons are set out in [Where authentication should live](/solution-architecture/access/where-authentication-lives.md). Two supporting facts are worth collecting at the same time: how many people sign in in the busiest hour, and whether users' workstations are domain-joined. The first decides whether a per-sign-in round trip to a directory is affordable. The second decides whether desktop single sign-on is available, which is frequently the best answer available in a Windows estate and is often not considered at all. ## How the four decisions interact They are separable, but not independent, and three interactions catch people out. **Where authentication lives constrains password strategy.** If OpenIAM verifies the credential, OpenIAM must hold one — which is why the password question follows immediately from the authentication question, and why "how would OpenIAM know the password?" is the very next thing a customer asks. **Password synchronization is not single sign-on.** They solve different problems and are routinely conflated. Synchronization means the same password works in several places, each of which still prompts for it. Single sign-on means the user is not prompted again. An estate can need both, and a design that delivers one while the sponsor expects the other is a failed programme with working software. **The per-application integration decision determines how much of the estate the gateway carries.** Every application behind the gateway puts OpenIAM on its request path; every application that speaks a federation protocol does not. That is an availability argument as much as an integration one, and it is why the per-application table is keyed on what the application supports rather than on what is quickest. ## Related * [Where authentication should live](/solution-architecture/access/where-authentication-lives.md) — the decision the rest of this part sits on. * [Password strategy](/solution-architecture/access/password-strategy.md) — synchronization, federation, or both, and what "in scope" means. * *The authentication model* in the Administration Guide — the objects that implement whatever this part decides. * Part 5, *Cross-organization federation* — what these decisions look like when a second identity provider is in the estate. *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.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.