Open-source alternative to AD FS Web Application Proxy

A proxy-based replacement for Web Application Proxy works by putting a gateway in front of each internal app. The user's browser reaches the proxy first, not the app. The proxy redirects the user to the identity provider, which is Keycloak, authentik or another OIDC source, and checks the returned token or assertion against a policy before any request reaches the app. Once the session is established, the proxy either forwards identity headers, such as a user name or group claim, or keeps the session at its own edge and passes only authorized requests through. Confirm which of these modes each candidate uses for your app types, because the app's own login logic, not the proxy, decides whether a forwarded header can be trusted.

The trust boundary therefore sits at the proxy, not at the app. Any header the proxy injects is only as trustworthy as the network path between the proxy and the app. Make the app reachable only from the proxy, strip client-supplied identity headers at the edge, and document which hosts may send them. Review these rules during design, because a misconfigured header path lets any internal caller impersonate a user. Ask the vendor how each candidate handles header stripping, upstream TLS and the signing or validation of identity data passed to the app.

Kerberos-protected apps need separate design work. Web Application Proxy, with AD FS, could perform Kerberos constrained delegation on the user's behalf, so the app saw the user's Active Directory identity. A proxy that only forwards OIDC or header identity does not do this by default. Inventory which apps depend on Integrated Windows Authentication, decide whether each needs delegation or a different identity model, and then plan the service accounts, Service Principal Names and Active Directory configuration those apps require. Treat this as its own workstream with its own test plan, not as a line item in the proxy rollout.

The cost of replacing Web Application Proxy is not one number. It is a set of components with different payers and different timing. On the AD FS side, the recurring cost sits in the Windows Server hosts that run the proxy role in the DMZ, their Windows Server licensing and CALs, the patching window, and the monitoring that goes with them. Those hosts do not disappear on day one, so the first thing to pin down is how long both paths will run in parallel and how many proxy nodes sit behind the load balancer today. Ask your Microsoft licensing partner or account team to confirm the license basis for each host, since it depends on your agreement and edition, not on this page.

On the replacement side, the open-source software itself carries no license fee for Pomerium Core (Apache-2.0) or authentik's open-source edition (MIT for most of the code). The costs that remain are the virtual machines or containers that run the proxy and identity components, the PostgreSQL database that authentik requires, the TLS certificates for each published hostname, and the load balancer rules that replace the ones AD FS imposed. Certificates and load balancing are mostly one-time design work followed by small renewal and change costs. Hosting is recurring. Confirm your certificate authority terms and whether your load balancer can run health checks and header forwarding for the new endpoints before you size anything.

Optional commercial editions change the picture. authentik Enterprise adds licensed per-user pricing and an external-user component on its pricing page, and Pomerium Enterprise is quoted on request. Those fees recur and scale with users or features, so they belong in the quote alongside support. The largest variable is usually implementation and operations labor: designing routes, mapping Kerberos and header-based apps, running cutover tests and maintaining upgrades. That labor is one-time for migration and recurring for operations. Ask any implementation partner for a fixed-scope quote that lists each component, who is paid for it, which items recur, and which assumptions about app count and user count it depends on.

The most visible change is that users stop arriving at an AD FS sign-in page on your own domain and start arriving at the sign-in experience of the new identity provider, reached through Pomerium or authentik's proxy provider. Users who open a published internal app will be redirected to the new login page, which may look different from the AD FS form they know. Plan a short notice before cutover that shows the new login screen, explains that the bookmark may change, and tells people who to contact if sign-in loops or fails. Confirm with your chosen product whether the login page can carry your logo and help text, and whether it supports the same username format your users type today, such as UPN or sAMAccountName.

MFA prompts and the password change flow need the most attention from the help desk. Today many organizations have AD FS prompt for MFA through a separate provider, and users may be surprised if the prompt wording, device enrollment steps or number of prompts changes. Before go-live, list every MFA method in use, test each one against a pilot group, and confirm how password expiry and change requests are handled once the identity provider is the one that checks credentials. Where passwords are validated against Active Directory through LDAP, expired-password messages may appear differently or not at all, so agree with the help desk on a fallback path for locked-out and expired accounts.

For the help desk, update the runbook before users are moved, not after. Replace references to AD FS admin pages, Web Application Proxy publishing steps and certificate renewal checks with the new product's equivalents, and add a first-line checklist covering clearing browser sessions, checking the bookmark URL, and confirming the user's account is synced. Record the expected sign-in redirect URLs for each published app so agents can tell a misconfigured route from a user error. Ask your implementation partner or the product's documentation which logs show a denied or failed sign-in, and make sure agents can read them. Run a tabletop exercise with the help desk on three or four realistic ticket types before the pilot begins.