Migrate from Shibboleth IdP to authentik

Shibboleth decides what each service provider receives through its attribute resolver and attribute filter policies, so the first step is an inventory of release rules grouped by service provider. In authentik, each SAML provider builds its assertion from its own property mappings, so write one mapping for each attribute a given provider needs and bind it only to that provider. Start with the authentik Shibboleth guide to confirm how the Shibboleth source is connected during cutover. Then compare each mapping's output with the attribute names and value formats each provider reads today. Implicit behavior, such as default values, scoped attributes or fallbacks when an attribute is missing, is the most common gap, so record each one as a separate item to verify before cutover.

The NameID is the value a service provider uses to identify a user, so a change in format or value can create duplicate or orphaned accounts. Before cutover, record the NameID format each provider expects, such as persistent, transient or email, and the exact value it receives from Shibboleth today. Configure the authentik SAML provider to send a matching format, and write a property mapping that produces the same stable value from the user attribute authentik holds. If Shibboleth issues persistent identifiers, confirm whether authentik can reproduce the same values for existing users, because a different value makes the provider treat the user as new. Confirm each expected value with the application owner and test it with a real login before any user is switched.

Shibboleth often derives affiliation or group values in its resolver from directory data, such as a role or department attribute. In authentik, group membership is stored on users and groups, and a property mapping can output a group or affiliation attribute from those values. Attributes received from the Shibboleth source can be stored on the user during enrollment and reused in later mappings, but confirm how your authentik version stores and maps source attributes before designing the chain. Check the output format closely, including letter case, multi-value handling and any scoped suffix such as a domain, since service providers often match these strings exactly. Derive values in a single, documented place so a later change does not produce different assertions for different providers.

Test each service provider separately with representative accounts that cover every affiliation, group and role the provider uses for authorization. Capture the SAML assertion from a Shibboleth login before any change, since the current IdP is the reference for what the provider expects. Then complete the same login through authentik in a staging environment, and compare attribute names, value formats, multi-value handling and the NameID against the captured baseline. Ask the application owner to confirm that the provider accepts the assertion and grants the same access. Repeat the comparison after every mapping change, and keep each captured assertion with the test result so the record supports the cutover decision.

Any release rule that is not written in the Shibboleth configuration or in the provider's own documentation needs confirmation from the application owner. Common gaps include attributes the provider requires but never logs, attribute values used for authorization decisions, and the behavior when an attribute is absent. Ask each owner for the list of attributes they consume, the required NameID format, the expected value formats, and whether any attribute controls access. Record the answers in a release register for each provider, one line per attribute, and use that register as the acceptance test. Do not treat a rule as confirmed until the owner has signed off on the register entry.

A team with SAML experience and access to the Shibboleth configuration can usually do this work. Most of the effort is inventory, mapping, per-provider testing and coordination with application owners, and each of those scales with the number of providers and release rules. The main cost drivers are the count of providers, the number of rules that are undocumented, how many owners must be scheduled for testing, and how often the team can make changes in a staging environment. Outside help is commonly bought as a fixed-scope engagement with written deliverables, such as the release register and the tested mappings. Ask any provider for a quote built from your per-provider register, and ask what is one-time work and what recurs after cutover.

When a Shibboleth release rule cannot be matched exactly in authentik, treat it as a documented deviation rather than an assumed match. First, ask the application owner whether the provider can accept the nearest equivalent value or a changed attribute name, and record the answer. Second, decide whether the gap affects authorization, because an attribute that drives access needs stricter sign-off than a display attribute. Third, check whether the change can be made on the provider side and track that change as a separate task. Keep the deviation in the release register with an owner, a date and the test result that shows the provider still grants the expected access. Do not claim feature parity for the migrated release set until every deviation has been signed off.

The cost depends on how many service providers you move, how complex their attribute and metadata requirements are, and how much testing each one needs. Software licensing for the Open Source edition is zero, so the spend is labor: planning, building providers and property mappings, testing with each application owner, and cutover support. Ask any partner for a quote built from a written scope that lists each service provider, the attributes it expects, and the test and rollback steps for each. Recurring costs are your hosting, PostgreSQL, and any support retainer you choose, while the migration itself is largely one-time work.

Duration depends mainly on application count, and each service provider adds its own metadata exchange, attribute mapping, and test cycle. A small set of SAML applications with simple attributes moves far faster than dozens of applications with custom attribute release rules or vendor-side change windows. Shibboleth can stay in place as a federated source while applications move one by one, which lets you cut over in waves rather than all at once. Ask for a timeline that groups applications by complexity and shows which owners must approve each wave.

Application owners must confirm their SAML entity IDs, assertion consumer URLs, signing certificates, required attributes and any name identifier format they depend on. The identity team must own the authentik side: source configuration, provider definitions, property mappings that replicate Shibboleth attribute release policies, and group and role decisions. Both groups must agree on a test plan and a rollback path for each application. Without named owners and a test window per application, cutovers stall, so confirm these commitments in writing before the schedule is set.

Yes, if the team has working knowledge of SAML metadata, certificates, and attribute release, and can read the authentik documentation for providers, sources and property mappings. The work also needs someone comfortable operating PostgreSQL, a container runtime or Kubernetes, and a reverse proxy, because authentik runs on that stack. Teams without this experience often spend the most time on attribute mismatches and certificate rotation during testing. A partner can take the full scope on a fixed-scope basis or cover specific gaps, such as attribute mapping reviews, while your staff keep ownership.

The Open Source edition covers the core SAML and OIDC provider functions needed to move service providers off Shibboleth, and its code is under the MIT license. The authentik pricing page lists Open Source as free with community support on Discord. Enterprise, priced at $5 per user per month billed annually plus $0.02 per external user per month, adds Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, and enhanced audit logging. Decide whether you need those features or the ticket-based support tier, and confirm your requirements against the authentik pricing page before you commit.

Shibboleth can remain as a federated identity provider through an authentik SAML source, which lets users who still sign in through Shibboleth reach applications that have not yet moved. That arrangement is useful during transition, but keeping it indefinitely adds a second authentication system to operate, patch and monitor. Each path also adds a dependency that must be documented in your access model. Plan a retirement date for the source, confirm which applications still rely on it, and check with your compliance team whether the dual path affects your audit evidence.

The most common failures are mismatched entity IDs, certificates that were not updated on the service provider side, and attribute names or formats that differ from what Shibboleth released. Name identifier formats and expected attribute sets also cause silent login failures that appear only after cutover. Test each service provider against a staging authentik instance using the same metadata it will use in production, and capture a sample assertion for comparison. Keep Shibboleth available as a fallback until every application has passed its test.