> 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/sso-approach-per-application.md). # Choosing an SSO approach per application Choose an integration per application — a modern protocol, an existing federation service, the Access Gateway, form fill — and recognise the applications this release cannot integrate directly. ## What this is, and when you need it Single sign-on is not one decision taken once. It is a decision taken per application, and the input is **what that application actually supports** — not what the programme would prefer, and not what the vendor's datasheet claims. This page is the decision table, the honest limits of each option, and the category everyone discovers late: applications this release cannot integrate directly. You need it when building the application inventory, which is early, because the answer determines effort per application and therefore the shape of the whole plan. An inventory that records "SSO: yes" for every row is not an inventory. ## The decision, keyed on what the application supports | The application… | Integrate it as | What it costs | What it buys | | -------------------------------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Supports **SAML 2.0** | A service provider trusting OpenIAM as identity provider | Certificate and metadata exchange, and a relationship with the application team | Real single sign-on: a signed assertion the application validates itself, its own session, and a logout it understands | | Supports **OAuth 2.0 or OpenID Connect** | An OAuth client of OpenIAM | Client registration, redirect URIs, and a decision about token lifetimes | The same, for modern and API-backed applications, plus a token model that suits non-browser clients | | Already federates with an **existing federation service** | Leave it there, and federate OpenIAM to that service | A trust between two providers, and a clear statement of which one is authoritative for which population | No re-integration work, and no flag day | | Is a **web application that reads identity from headers, cookies or query parameters** | Behind the Access Gateway, with injection | OpenIAM on the request path for every hit, and exclude rules that must not be forgotten | An application that was never built for SSO behaves as if it were, without being changed | | Is a **web application with only its own login form** | Behind the Access Gateway, with form fill | Everything above, plus a dependency on password synchronization | The credential-injection style of SSO — the user never sees the login page | | Is a **SOAP service expecting credentials in the envelope** | Behind the Access Gateway, with SOAP header injection | As above | A service integrated without touching it | | Has **domain-joined browser users and no protocol** | The Access Gateway with Kerberos desktop SSO | Service principals, a keytab and the domain team's lead time | No login page at all, using credentials the workstation already holds | | Is a **non-browser API client** | OAuth 2.0 with a bearer token | Token handling in the client | The right model. The gateway's session assumes a browser and a redirect | | Is a **thick client, a terminal application, or anything without an HTTP front door** | **No SSO path in this release.** See below | — | — | Read the table top to bottom. The order is the order of preference, and the reason is not aesthetic: every row below the third puts OpenIAM on the request path or in possession of a credential, and every row above it does not. ## Prefer a protocol wherever one exists Where an application can speak SAML 2.0 or OpenID Connect, use it, even when the gateway would be faster to configure. A federation protocol gives the application a signed assertion or a token it validates itself, a session it owns, and a logout it understands. The gateway gives it a header it must trust blindly, and makes every single request to that application depend on OpenIAM being up and responsive. That last point is the one to weigh at the architecture level rather than the application level. The gateway asks OpenIAM, on every protected request, whether this user may have this URL and what should be injected. **The gateway's availability is OpenIAM's availability.** An estate that puts sixty applications behind the gateway has made OpenIAM a tier-one dependency for sixty applications; an estate that federates fifty of them and proxies ten has not. Design the split deliberately. A second architectural property of the gateway: configuration changes take effect on a cache timer rather than on save. That is fine operationally and it matters for planning — a change and its rollback each have a propagation delay, so gateway changes are not a same-minute rollback path. ## What the gateway can actually do Stated precisely, because the gap between what a reverse proxy is imagined to do and what this one does is where projects lose time. **It can present identity to the application** as request headers, as query-string parameters, as cookies, as fields posted to the application's own login form, and as headers inside a SOAP envelope. The values it injects come from a small, closed set of sources: a handful of user-profile attributes (including the user's principal and the password held for that managed system), a static value, or a Groovy script — the script being the general answer for anything the closed set does not cover. **It can authenticate the user** by an existing OpenIAM session cookie, by a client certificate, by Kerberos/SPNEGO for domain-joined workstations, or by sending them to OpenIAM's sign-in flow and back. SPNEGO support is part of the shipped module. **It can rewrite the response** — substituting absolute URLs, fixing redirects — which is what makes some applications proxyable at all. **It cannot authenticate to the application on the user's behalf using Windows-integrated authentication.** There is no NTLM or HTTP Basic delegation to the upstream application. If the application itself demands one of those from its client, the gateway is not the integration. Three application behaviours defeat the gateway outright, and each is a go/no-go question worth asking before the application is scheduled: **Absolute URLs everywhere.** An application that writes its own hostname into links, form actions and script sources sends users straight past the gateway. Response substitution fixes this per URL, which is maintainable for a page or two and not for an application that does it throughout — least of all where the URLs are assembled by JavaScript in the browser, where no response rewriting can reach them. **Client-address or host checks.** An application that refuses requests that did not come from where it expects will refuse every request once they all arrive from the proxy. **A CAPTCHA or a script-signed login form.** Form fill is impossible against either. The purpose of a CAPTCHA is that a machine cannot complete the form, and the gateway is a machine. ## Form fill, and what it really depends on Form fill is the answer for the legacy application with its own user database and no intention of changing — the case that comes up in every workshop. The gateway posts the application's own login form on the user's behalf, and the user never sees it. The dependency to design for is the credential. The value injected as the password is the one OpenIAM holds for that user on the gateway's managed system, so **form fill works because the application's local password is kept equal to a password OpenIAM knows** — which is password synchronization, and which means the application must be a managed system with a connector that can set passwords. Where that is not possible, a Groovy script can supply the value from somewhere else, and you have just taken ownership of a credential store. So form fill is not a way to avoid integrating an application. It is a way to avoid changing its login page, at the cost of provisioning and synchronizing into it. Say that plainly when it is proposed as the cheap option. ## Applications this release cannot integrate directly This category exists, it is larger than sponsors expect, and a guide that does not name it will be discounted by the architect who has three of them. These are the applications that match none of the mechanisms in the 2026.8.1 release: no modern protocol, no gateway-compatible behaviour, and no login form to fill. **Thick clients** that authenticate directly against their own server or database, with no HTTP layer for a proxy to sit in and no ability to consume a token. **Terminal and green-screen applications** reached over a terminal protocol. **Embedded and appliance interfaces** with a fixed local credential. **Anything that cannot be changed and speaks no protocol this release speaks** — RADIUS, CAS and WS-Federation are not in the 2026.8.1 catalogue, so an application whose only option is one of those has no direct SSO path here either. For all of them, the useful design position is: **SSO is out of scope; lifecycle and governance are not.** | What you can still do | Why it is worth doing | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------- | | Provision and de-provision the account through a connector | The leaver process reaches it. This is the majority of the risk | | Synchronize the password | The user has one password even though they are prompted for it separately | | Include its entitlements in certification | An auditor can see who has access and that somebody attested to it | | Front it with a jump host or a privileged-access product | The session becomes controllable even where the authentication is not | | Put it on the modernisation list, with the cost of not doing so recorded | The decision is visible rather than inherited | The failure mode to avoid is silence: an application that is neither integrated nor recorded as un-integrated simply drops out of the programme and reappears in an audit finding. ## What we recommend **Decide per application, from an inventory that records what each one actually supports.** Three columns — protocol supported, integration chosen, effort — will do more for the plan than any amount of strategy. **Prefer a protocol; use the gateway for what has none; use form fill only where there is no other option.** Each step down that ladder increases coupling to OpenIAM. **Keep a deliberate ceiling on how much of the estate sits behind the gateway**, and treat crossing it as an availability decision rather than an integration one. **Test the three go/no-go behaviours before committing an application to the gateway** — absolute URLs, client-address checks, CAPTCHA on the login form. Each is cheaper to discover now than after the configuration exists. **Where an application already federates with an existing federation service, leave it there** and federate OpenIAM to that service instead. Re-integrating working applications is effort spent to make a diagram tidier. **Name the applications SSO cannot reach in this release, explicitly, and govern them anyway.** The circumstance that changes this advice is an estate whose legacy applications are all due for replacement inside the programme's horizon. There, the gateway is a bridge with a known end date, and loading it heavily is a reasonable trade. ## What OpenIAM does not do here * **No WS-Federation, no CAS, no RADIUS in this release.** Federation is SAML 2.0 and OAuth 2.0 / OpenID Connect. * **The gateway does not perform NTLM or HTTP Basic authentication to the upstream application** on the user's behalf. * **The gateway is an HTTP reverse proxy.** It cannot front a thick client, a terminal protocol or any non-HTTP application. * **Response rewriting cannot reach URLs built by JavaScript in the browser.** An application that assembles its own absolute URLs client-side cannot be fully proxied. * **Form fill cannot defeat a CAPTCHA or a script-signed login form**, and no configuration works around it. * **Injected values come from a closed set of sources.** A handful of user-profile attributes, a static value, or a Groovy script; anything else is the script. * **The gateway holds no policy of its own.** It asks OpenIAM on every protected request, so it is as available as OpenIAM is, and no more. * **Gateway configuration propagates on a cache timer**, so neither a change nor its rollback is immediate. ## Related * [Password strategy](/solution-architecture/access/password-strategy.md) — form fill depends on it. * [Entry points and the user's experience](/solution-architecture/access/entry-points.md) — how users reach whatever you have integrated. * *How the Access Gateway works* and *Give the application the authenticated identity* in the Administration Guide — the gateway's model and its injection mechanisms. * *OpenIAM as a SAML identity provider* and *OAuth 2.0 and OpenID Connect* in the Administration Guide — the two protocol paths. *Applies to OpenIAM 2026.8.1. Last reviewed 13 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/sso-approach-per-application.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.