When authentik's WS-Federation provider fits SharePoint sign-in
If your SharePoint or other Windows-integrated applications sign users in through AD FS and you want that sign-in path to run on infrastructure you control in authentik, the relevant fact is this: authentik 2026.2 added an Enterprise WS-Federation provider for applications such as SharePoint. It supports only the SAML2 token type and browser-based passive sign-in. It does not provide WS-Trust active authentication or Metadata Exchange endpoints, so any client or integration that depends on those will not work through this provider. Treat it as a scoped option for relying parties that fit this pattern, not as a complete AD FS replacement. The provider requires an authentik Enterprise license, which is priced at $5 per user per month billed annually plus $0.02 per external user per month, according to the authentik pricing page. Ask your authentik partner or licensing contact to confirm current terms before you budget.
Start by inventorying every relying party trust on your AD FS farm and sorting them by protocol and sign-in behavior. Applications that use passive browser sign-in with SAML2 tokens are candidates for this provider. Applications that rely on WS-Trust active authentication, on Metadata Exchange, on other token types, or on AD FS features outside this scope need a separate path. Microsoft's guidance is to move modern-protocol applications first and to handle older-protocol applications through Application Proxy or Secure Hybrid Access partners, so use the AD FS application migration stages guidance as a checklist for sorting. Confirm with the SharePoint and Windows application owners which sign-in paths their users and services actually exercise before deciding anything.
Which WS-Federation settings and token choices to decide before build
This table compares the main choices you face before configuring the authentik WS-Federation provider: token type, sign-in mode, licensing, rollout order and metadata handling. Read each row as a constraint you accept or design around, and settle the first two rows before any relying party is created.
| Decision | Option | Trade-off and when it fits |
|---|---|---|
| Token type | SAML2 token only | The provider supports only the SAML2 token type (authentik 2026.2 release notes). Confirm that your SharePoint or Windows relying party accepts SAML2 tokens before you commit, because any app that needs a different token format will not work through this provider. |
| Sign-in mode | Passive browser sign-in | Browser-based passive sign-in is the supported model. Users are redirected to authentik from the browser, so fits web access to SharePoint. Desktop clients or services that need WS-Trust active authentication are not covered, and you should test those clients separately. |
| Sign-in mode | WS-Trust active authentication | Not provided by this provider (authentik integrations catalog). If an application depends on active authentication, plan a different integration path or confirm the requirement with the application vendor before the build starts. |
| Enterprise licensing | Enterprise edition for the WS-Federation provider | The provider is an Enterprise feature, and its code sits under the separate enterprise license in the authentik/enterprise/ directory. Ask for a quote covering the number of users and external users in scope, and confirm which environments (test, staging, production) need a license. |
| Rollout order | Move low-risk relying parties first | Start with one site or application that has few dependencies and a known set of users. Microsoft's migration guidance favors applications on modern protocols first, and older protocols are handled separately, so a pilot tests the claim mapping and sign-in flow before wider cutover. |
| Rollout order | Keep AD FS for applications not yet proven | Running both AD FS and authentik in parallel lets you move relying parties one at a time. The constraint is that each relying party trust must point to one token issuer at a time, so record which application uses which issuer. |
| Metadata handling | Share federation metadata manually | Metadata Exchange endpoints are not provided. Exchange the metadata file or the relevant endpoint values by hand, and version and check each exchange, because a missed update will break sign-in without an obvious error. |
| Signing certificate | Plan certificate replacement with relying parties | When a token-signing certificate changes, every relying party must receive the new certificate or sign-ins fail (Microsoft Learn, AD FS requirements). Decide who owns certificate changes and how each SharePoint or Windows relying party is updated before the first renewal date. |
Set up the WS-Federation provider for a SharePoint relying party
This sequence takes you from licensing and version checks through a working WS-Federation provider in authentik, a relying party trust in SharePoint or the Windows application, and a tested cutover with a rollback path. The output is a verified passive sign-in flow you can move users onto.
Confirm Enterprise licensing and version
Confirm that your authentik edition includes the Enterprise WS-Federation provider, which was added in authentik 2026.2 and supports only the SAML2 token type. Check the version against the supported releases in the authentik security policy and the release notes for your target version. Ask your authentik contact to confirm which features your subscription covers before you design anything else. Done when you have a written note of the edition, the version and the token type you will use, and the Enterprise license is active in the admin interface.
Deploy or confirm the server and PostgreSQL
Confirm that the authentik server and worker containers are running and that PostgreSQL holds all configuration and data, since no Redis is required in current releases. Use a separately managed PostgreSQL for production rather than the bundled database if you deploy on Kubernetes. Confirm that the public hostname used by SharePoint resolves and that TLS is valid on it, because the federation endpoints must be reachable by browsers. Done when the admin interface loads over the production hostname and a test user can sign in to it.
Create the provider and application in authentik
In the admin interface, create a WS-Federation provider with the SAML2 token type, then create an application that uses it. Record the realm or relying party identifier, the sign-in endpoint and the signing certificate that authentik issues, because the relying party needs all three. Bind the application to a policy or group so only the intended users can sign in. Done when the provider saves with the SAML2 token type selected and the application appears in the user portal for a test account.
Configure the relying party trust in SharePoint or the application
Add the authentik details to SharePoint or the Windows application as a federated identity provider, using the realm identifier, sign-in endpoint and certificate you recorded. Confirm with your SharePoint administrator how the platform expects to receive the certificate and whether your SharePoint deployment version supports the federation method you chose, since support differs between Microsoft 365 and on-premises editions. Do not rely on metadata exchange or WS-Trust active authentication, which the provider does not offer. Done when the trust is saved and the sign-in page redirects a test browser to authentik.
Map claims and groups
Define the claims that SharePoint needs, typically the user principal name or email identifier and the group memberships used for site permissions. Map them from authentik user attributes and groups using property mappings, and confirm the exact claim names the relying party expects. Keep group names stable, since SharePoint permissions reference them. Done when a test user's issued token contains the expected identifier and group claims, and a user outside the target groups receives no site access.
Test sign-in in a non-production tenant
Run the full passive sign-in in a non-production SharePoint site or tenant. Test with a user from each relevant group, a user without access, a user with an expired password and a sign-out followed by a new sign-in. Check the browser redirects, that the session lands on the intended site, and that the authentik event log records each sign-in. Document each result, including any claim or certificate errors. Done when every test case behaves as your access design requires and the failures you found are fixed and retested.
Cut over with a rollback path
Plan the production change with a window agreed with the business owners. Keep the existing AD FS trust or sign-in path in place and disabled only by a documented switch, so you can revert the relying party setting quickly if sign-in fails. Before you switch, record the current configuration and the certificate in use. After cutover, confirm sign-in for a pilot group, then extend to all users. Done when the production sign-in works for the pilot group, the rollback steps have been rehearsed and the old trust is retired only after a stable period you have agreed.
Security and operational risks of running WS-Federation from authentik
Running WS-Federation from authentik moves trust, claims, MFA and patching decisions into your own platform. The cards below cover the failure points that most often break or weaken SharePoint and Windows application sign-in, and what to check before go-live.
Signing certificate rotation on both sides
AD FS documents that when the token-signing certificate changes, every relying party must receive the new certificate or its sign-ins fail. The same discipline applies here: authentik's signing key and the certificate or metadata each SharePoint or Windows relying party trusts must be rotated in a planned order. Confirm the rotation runbook and overlap window with your SharePoint and identity owners before the first key change.
Claim mapping errors
WS-Federation relying parties depend on the claims they receive, such as the user identifier and group or role values that drive SharePoint permissions. A mapping that sends the wrong identifier, or a group claim that is empty for some users, can grant access to the wrong people or lock out valid ones. Test with a sample of accounts from each group and compare the issued SAML2 assertion against what the application expects.
MFA enforcement at the authentik level
Because the WS-Federation provider handles passive browser sign-in, the second factor is enforced by the authentik flow and policies that run before the assertion is issued, not by the SharePoint farm. Confirm that the authentication flow bound to the provider requires the factors your policy demands, and that no bypass exists for users who reach SharePoint through older clients. Document who can change that flow.
Audit logging on the Enterprise tier
WS-Federation is an Enterprise feature, and enhanced audit logging is listed among Enterprise-only features on the pricing page. Before relying on it for evidence of who signed in to SharePoint and when, confirm which events the license tier records, where they are forwarded, and how long your organization retains them. Ask for a sample export during the pilot rather than assuming the events you need are present.
Patching against the supported version list
authentik publishes a list of versions that receive security fixes and announces security releases at least 24 hours in advance. Your patch process must map each deployed version to that list, schedule upgrades inside the advance notice window, and test WS-Federation sign-in after every upgrade. Treat an unsupported version as an open risk and record the owner and date for closing it.
Replacing AD FS for these applications: what to inventory first
Microsoft recommends migrating to Microsoft Entra ID rather than upgrading AD FS, and that recommendation should shape the inventory. Before you decide whether authentik replaces a specific AD FS relying party trust, list every application that depends on the farm, including each SharePoint site, line-of-business app and extranet partner portal. Microsoft's AD FS decommission resources include an AD FS Migration Readiness Script that runs on the AD FS server and reports which applications are ready to migrate, and an AD FS application activity report in Entra ID that shows which applications still sign users in. Run both, then compare the output with your own list. Gaps between the two usually point to applications nobody has documented.
Sort the applications by protocol. Microsoft's guidance is to move applications that already use SAML or OpenID Connect first, while applications on older protocols are handled through Application Proxy or a Secure Hybrid Access partner. Confirm for each WS-Federation relying party that the authentik provider covers its sign-in pattern: the authentik Microsoft 365 WS-Federation guide describes browser-based passive sign-in only, with no WS-Trust active authentication and no Metadata Exchange endpoint. Any application that depends on active authentication or metadata exchange needs a separate design decision before you retire the AD FS trust for it.
Map every extranet dependency before you decommission anything. External users reach AD FS through the Web Application Proxy role, which cannot run on the same computer as a federation server, and third-party proxies must support the MS-ADFSPIP protocol. Record which applications are published through the proxy, which certificates the proxy uses, and which partners depend on those URLs. Also record each relying party's copy of the AD FS token-signing certificate, because a change to that certificate breaks every relying party that has not been updated. Ask your authentik partner to confirm the token type, claim rules and certificate handling for each application in writing before cutover.
Limits to confirm before committing to authentik for SharePoint
The authentik WS-Federation provider covers browser-based sign-in for SharePoint and similar relying parties, but it is narrower than AD FS. The cards below list the protocol gaps, licensing and tenant conditions, and the per-application testing you should complete before you replace any AD FS trust.
No WS-Trust active authentication
The provider supports browser-based passive authentication only. Any client, service or tool that expects WS-Trust active sign-in, where a non-browser client presents credentials to a security token service, will not work through this provider. Inventory every client that calls your AD FS endpoints, not just the browser sign-in path, and confirm with authentik how each one will authenticate.
No Metadata Exchange endpoint
The provider does not publish a Metadata Exchange endpoint, so relying parties cannot pull federation metadata automatically. You will need to exchange metadata files manually and repeat that step whenever signing material or endpoints change. Ask authentik to confirm the exact metadata artifacts it provides and plan a documented update process for each relying party.
SAML2 token type only
The Enterprise provider issues SAML2 tokens only. Applications that were configured for SAML1.1 tokens, or that require a token type other than SAML2, cannot use this path without a change on the application side. Review the token format each relying party expects in its current configuration before you plan the cutover.
SharePoint plan and tenant requirements
Confirm which SharePoint deployment you run before you design the trust. SharePoint Server 2019 is on the Fixed Lifecycle Policy, with extended support ending in July 2026, while SharePoint Server Subscription Edition follows the Modern Lifecycle Policy. Confirm with Microsoft and your own licensing how each option handles external identity providers, and check the SharePoint tenant limits that apply to your content.
Enterprise license cost basis
The WS-Federation provider sits in the Enterprise code under a separate license, and the authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Ask for a quote that states the user counts used for each rate, whether external accounts are in scope, and whether Enterprise Plus extras are needed for your support or FIPS requirements.
Test each relying party's behavior
Every relying party handles claims, signing certificates, logout and error paths in its own way, so the provider's documented support does not prove a given application works. Build a test matrix per application covering sign-in from browser, mobile and desktop clients, claim mapping, session expiry and failure handling, and run it in a non-production tenant before you retire the AD FS trust.
Questions buyers ask about authentik and AD FS replacement
What does the authentik Enterprise license cost and what does it cover?
The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The WS-Federation provider is an Enterprise feature, so a deployment serving SharePoint through it needs an Enterprise subscription regardless of the size of the pilot. Enterprise also unlocks other features such as enhanced audit logging and mTLS client certificate authentication. Ask the vendor how external users are counted for your SharePoint audience, and confirm whether the price shown applies to your region and contract. DeployOpen's own fees for scoping and building are separate and follow from a written scope.
How long does an authentik WS-Federation pilot take?
No duration figure is supplied for this work, so treat any number you hear as a question to confirm against your scope. Duration is driven mainly by how many relying parties you move, whether SharePoint is the only one or sits alongside Windows applications, how your MFA and conditional access rules map onto authentik policies, and how many test users you can give access to during the pilot. Certificate handling and claim mapping also take time, because the token type is SAML2 only and passive browser sign-in is the only supported flow. A pilot covering one site collection with a small test group is shorter than a multi-application cutover. Ask for a written plan with named test cases before work starts.
Can our own team deploy this without outside help?
Yes, a capable identity team can deploy authentik and configure a WS-Federation provider, provided it has time to learn the Enterprise feature set and the Microsoft 365 side of the trust. The harder parts are usually not the install itself but the trust configuration, certificate lifecycle, and validating sign-in from real browsers across SharePoint clients. Compare the internal cost of that learning curve and the time the team can spare against a fixed-scope engagement. Outside help is most useful for scoping, for a test plan that covers every relying party, and for a documented runbook your staff can operate afterward. Deployment on infrastructure you control is also the same whether DeployOpen or your team does the build.
What does the work need from our identity and SharePoint admins?
Both teams are needed from the start. Identity admins own the authentik deployment, the Enterprise subscription, user and group sources, MFA and access policies, and the signing certificate lifecycle. SharePoint and Microsoft 365 admins own the tenant trust configuration, the list of site collections and apps that will accept the new sign-in path, and test accounts with the right licenses. Both groups must agree on a change window and on how users fall back if sign-in fails. Confirm early which Microsoft 365 features rely on the current AD FS trust, since those dependencies decide what is in scope.
Can authentik replace the whole AD FS farm?
Not necessarily in one step, and this topic does not establish that it can replace every AD FS function. The authentik WS-Federation provider supports browser-based passive sign-in with the SAML2 token type. It does not provide WS-Trust active authentication or Metadata Exchange endpoints. Microsoft recommends migrating to Microsoft Entra ID rather than upgrading AD FS, and its migration guidance moves modern SAML and OpenID Connect apps first. Start by inventorying which relying parties use passive sign-in, which need active authentication, and which depend on extranet publishing through the Web Application Proxy role. Those answers determine whether authentik covers the farm or only part of it.
What do we need to check before retiring AD FS for these apps?
Check each relying party against the protocol it actually uses before any cutover. Microsoft's AD FS Migration Readiness Script runs on the AD FS server and assesses which applications are ready to migrate, and the AD FS application activity report in Entra ID shows which apps still send sign-ins. Keep AD FS running in parallel until every app has a tested fallback. Also remember that changing a token-signing certificate fails sign-ins for any relying party not updated with the new certificate, so plan that rotation as its own change.
Does the SAML2-only token type limit what SharePoint can do?
It limits the sign-in path, not the content SharePoint stores. The provider issues SAML2 tokens and supports passive browser sign-in only, so any relying party that requires another token type or WS-Trust active authentication is not a fit for this provider. Test every client path your users rely on, including desktop apps and mobile sign-in, before deciding scope. Storage and content limits in SharePoint are a separate question and are governed by Microsoft's own service limits.
How DeployOpen scopes WS-Federation work with authentik
DeployOpen scopes WS-Federation work as a fixed-scope engagement, with the written scope agreed before any build starts. The scope document is where most of the risk is controlled, so it names every relying party (SharePoint sites, Windows applications and any other WS-Federation consumers), the claims each one expects in its SAML2 token, the test plan for each relying party, and the cutover sequence. Because the authentik provider supports only the SAML2 token type and passive browser sign-in, the scope also records which applications depend on WS-Trust active authentication or Metadata Exchange, since those are not provided and must be handled another way or moved out of scope. The deliverables are written against that inventory, not against a generic SSO template.
The work is delivered inside your own infrastructure, on the authentik instance, PostgreSQL and outpost hosts you operate, and the scope should state who holds administrative access to each of them. Our practice is to agree in writing which relying party changes are made by DeployOpen, which are made by your team, and how signing certificates are rotated, since a changed token-signing certificate requires every relying party to be updated or sign-ins fail. Ask any partner, including us, to show how a rollback of one relying party works without affecting the others. Ongoing support, upgrades of authentik and periodic re-testing of relying parties are available as a retainer, which you can add once the initial scope is delivered. Please confirm current Enterprise licensing terms directly with authentik before finalizing the scope, because the WS-Federation provider sits in the Enterprise license area.
