Legacy applications
Modern identity for applications that cannot federate.
Bring legacy web applications under your identity provider without rewriting them.
The trigger
Some applications were never built to use OpenID Connect or SAML.
A business-critical web application may identify its users from a trusted identity header, or from its own login page, because that is what it was built to do. Rewriting it is rarely practical, and the modernization program around it still has to move.
Not every legacy application needs the same treatment. Some can federate once a change is made in the application’s own administrative interface. This page is about the ones that cannot federate at all.
The result
01 / Route
The identity provider still runs sign-in.
Users authenticate against the approved provider, which continues to run its own authentication journey.
02 / Contract
The application keeps the contract it has.
Older web applications use a protected path that supplies identity in the form the application expects, so the application itself does not change.
03 / Record
The application joins the estate model.
Its provider path, owner, and approved configuration sit with the rest of the estate, so a later provider change does not mean revisiting the application.
If you run a gateway today
The runtime takes the place a gateway holds today.
Architects usually call this role a gateway: the component in front of a legacy web application that establishes who the user is and passes that identity to the application. The Application Identity Runtime takes that place.
What changes is what sits behind it. The application becomes part of the estate model rather than a separate piece of infrastructure with its own configuration to maintain, so the decisions about it are visible alongside every other application.
Applications move one at a time.
Your implementation team decides
- The applications in scope and what each needs to identify a user
- The approved identity-provider path for each one
- The order in which applications move
Authonomy holds
- The application-facing identity contract, including the protected path
- The relationship between the application and its provider path
- The intended configuration and evidence of the resulting state
Identity providers continue to run authentication, while the application retains its own permissions and session. Which applications can be brought in this way depends on what each one requires to identify a user, and that is the first thing to work through.
See how the parts fit together →Bring one legacy application.
We’ll look at what it needs to identify a user, the provider path it should use, and what moving it would involve.