Connecting a Shibboleth IdP as a SAML source in authentik
A university or public-sector team that already runs a Shibboleth identity provider can let its users reach authentik-protected applications without issuing a second set of passwords. authentik's documented method is a SAML source: Shibboleth is configured as a federated identity provider, and authentik trusts it as the upstream party that authenticates the user before authentik creates or matches a local account. At login, the user is redirected to Shibboleth, signs in with the campus credentials and any second factor Shibboleth enforces, and returns to authentik with a SAML assertion. authentik then applies its own enrollment and matching rules and issues its own session and tokens to the applications behind it.
The source does not replace the Shibboleth IdP's user store, password policy, multi-factor rules or release decisions. Accounts, credentials and lockout behavior stay with the campus IdP, and authentik only sees what the IdP sends in the assertion. That split has consequences: if a user is disabled in the campus directory, authentik will not know about it until the next federated login, and any attribute authentik needs for group or role decisions must be released by Shibboleth's attribute resolver and attribute release policy. Confirm both points against the authentik Shibboleth guide and with the campus identity team before design work starts.
Before configuring anything, the team should agree on three decisions with the Shibboleth administrators: which SAML metadata and signing certificates authentik will trust, which attributes Shibboleth will release (for example, a stable unique identifier and the attributes used for authorization), and how first logins map to existing authentik users. Ask for the IdP metadata and the release policy in writing, and test with a small pilot group. The Shibboleth guide in the authentik documentation lists the exact source settings and the steps for exchanging metadata, so treat it as the reference for field names and sequence.
What you need before configuring the Shibboleth source
Four things need to be in place before anyone touches the SAML source: a supported authentik release, a Shibboleth IdP you can reach, a stable name with HTTPS for authentik, and a named owner on the Shibboleth side. Each one changes the work in the next step, so confirm them in this order.
Target an authentik release line
Start by choosing the release line you will deploy and confirm it appears in the supported versions listed in the security policy. The latest release on the releases page is not automatically the right target for a production install. Check the upgrade rule before you install, because authentik upgrades must step through versions in sequence. If you are moving from an older deployment, record the current version now so the path to the target is planned, not guessed.
Decide where PostgreSQL lives
authentik stores its configuration and data in PostgreSQL, and that dependency is set by your install method. Docker Compose suits test setups and small-scale production, while the Kubernetes Helm chart bundles a PostgreSQL meant for demonstration and testing. For production, confirm a separately managed PostgreSQL with backups and sizing before you configure federation, since source mappings and user records depend on it.
Confirm Shibboleth metadata and signing certificate
The SAML source needs the Shibboleth IdP's metadata and the certificate it uses to sign assertions. Ask the Shibboleth operations team for the metadata URL or file, and confirm it is the production IdP, not a test instance. Record the certificate's expiry date and who rotates it, because a rotation the source does not know about will break every login until the metadata is refreshed.
Register a DNS name and HTTPS certificate
The SAML exchange depends on authentik's public address, so the DNS name and TLS certificate must be settled before you register authentik with Shibboleth. Changing the hostname later means updating the entity identifier, the assertion consumer URL and the relying party entry on the IdP side. Confirm that the certificate chain is trusted by the Shibboleth host and that the name resolves from every network where users sign in.
Name an owner in Shibboleth operations
Someone in the Shibboleth operations team must approve the relying party registration, release the attributes authentik needs, and agree on a change window for certificate or metadata updates. Without a named owner, requests for attribute release stall, and the first login problem becomes a support ticket with no one to answer it. Agree on who approves changes and how they are communicated before the build starts.
How to configure the SAML source step by step
This sequence connects a Shibboleth identity provider to authentik as a SAML source, so that users from the university or institution can sign in through their existing Shibboleth account. Each step ends with a check that confirms the trust relationship, attribute flow and login path work before wider rollout.
Confirm the authentik base URL and entity ID
Before anything is exchanged, the team that runs authentik and the team that runs Shibboleth agree on the public base URL authentik will be reached at, and on the SAML entity ID that authentik will present as its service provider identity. Both values must match exactly what is registered on the Shibboleth side, including scheme, host and any trailing path elements. Confirm the base URL resolves over HTTPS from the networks your users and the Shibboleth IdP can reach. Done means both teams have written down the same two values and the base URL loads in a browser without certificate warnings.
Obtain the Shibboleth IdP metadata
Ask the identity team that operates the Shibboleth IdP for its SAML metadata document, which describes its entity ID, signing certificate and single sign-on endpoints. Confirm with them whether the metadata is published at a stable URL or must be supplied as a file, and whether they also need authentik's service provider metadata before they can register it. Check that the certificate in the metadata is current and that its expiry date is known to both teams. Done means you hold a complete metadata file or URL, and you have a named contact for certificate rollover.
Create the SAML source in authentik
In the authentik admin interface, create a new SAML source under the sources area and give it a slug that identifies the institution, since this slug becomes part of callback and login URLs. Enter the entity ID and name for the source as agreed in the first step. Import the Shibboleth metadata by URL or by pasting the XML, depending on what the IdP team supplied. Save the source and review the endpoints and certificate fields that authentik populated from the metadata. Done means the source saves without validation errors and the displayed IdP entity ID matches the one the Shibboleth team confirmed.
Set binding and signing options
Apply the binding and signing settings that the authentik Shibboleth guide specifies for this source type, and confirm them against the Shibboleth IdP configuration rather than relying on defaults. Check which SAML binding the IdP uses for its single sign-on endpoint and whether it expects signed authentication requests or signed responses. Make sure the signing certificate authentik uses for requests matches what the Shibboleth side has registered. Done means both sides agree on binding and signature expectations, and a test authentication request is accepted by the IdP without a signature or binding error.
Map Shibboleth attributes to authentik user fields
Work with the Shibboleth administrators to confirm which attributes the IdP releases to the service provider, such as the identifier used as the username, the email address and any name fields. Note that releasing an attribute is a decision the institution controls under its own attribute release policy, so ask for exactly the attributes authentik needs. In authentik, map each released attribute to the corresponding user field in the source's property mappings, and set the user matching field so that returning users are correlated to the right account. Done means a test assertion from the IdP populates username and email fields in authentik with the values the Shibboleth administrator expects.
Add the source to the login flow
Add the new SAML source to the authentication flow that users see when they start a login, so that a Shibboleth sign-in option appears alongside any existing methods. Decide whether users are shown the source on the default login page, on a separate page, or only when they reach a specific application, and align that choice with the flow's identification stage. Keep at least one local administrator path available so that a misconfigured source cannot lock out administrators. Done means the login page lists the Shibboleth option and the flow runs to completion when the source is selected.
Test with a pilot account
Choose a small group of pilot accounts that hold known institutional credentials and represent the different affiliations or roles that will use the source. Have each pilot sign in through the Shibboleth option, then review the user record in authentik to confirm the username, email and any mapped fields match the expected values. Test a second login to confirm the account is matched to the existing user rather than duplicated, and test one account that should be refused, if the institution has one. Done means every pilot account reaches the expected application with the correct identity, and the team has a written record of the results before enrollment widens.
How attributes and identities map, by role
The identity owner runs the Shibboleth IdP and decides which attributes leave it. authentik can only use what the IdP releases to it in the SAML assertion, so the first task is to agree a release list for the authentik service provider. Attribute names vary between institutions, so confirm them against the IdP's attribute resolver and release policy before assuming any standard set applies.
- Persistent identifier: Ask for a stable, unique identifier such as eduPersonPrincipalName (illustrative name), and confirm that its value does not change when a person's role changes.
- Affiliation data: Ask for affiliation-type attributes, such as eduPersonAffiliation or eduPersonScopedAffiliation (illustrative names), and confirm the exact values sent for staff, students and affiliates.
- Release scope: Release only the attributes each authentik application needs, and ask for a written list with the reason for each.
- Metadata and certificates: Agree the entity ID, signing certificate and metadata exchange method with the authentik administrator, and record the expiry date of the signing certificate.
Check that the release list in the IdP matches the attribute mappings in authentik before the first test login. The authentik Shibboleth guide describes the source settings these names feed into.
The application owner decides how a Shibboleth identity becomes an authentik user and which groups or policies grant access. authentik maps incoming SAML attributes to user fields through the source's property mappings. The username is set from one chosen attribute, so that choice determines how accounts are matched on later logins and whether an existing local account is linked or duplicated.
- Username choice: Pick a stable, unique attribute for the authentik username. A persistent principal identifier usually holds up better over time than a display name or email alias, which may change. Confirm uniqueness across the whole user population before the first login.
- Group and affiliation mapping: Map affiliation values to authentik groups, then bind those groups to applications and policies. Affiliation is usually a coarse signal, so combine it with a more specific group where an application needs finer control.
- Matching existing accounts: Decide whether Shibboleth logins may link to accounts that already exist. Test this on a sample of accounts first, because a wrong match would give one person another person's access.
- Test identities: Build an illustrative set of test identities covering each affiliation value, and confirm the resulting groups and application access in authentik.
Document the mapping table and get it signed off by the identity owner before go-live, since any later change to the username attribute affects every account.
The privacy or records officer determines whether identity attributes count as education records and what the institution must control around them. Under FERPA's regulations, an institution that receives funds from the US Department of Education must limit access to student records to school officials with legitimate educational interests and must keep a record of disclosures. Whether a given attribute falls under those rules is a legal question to settle with counsel, not a configuration question.
- Attribute minimization: Limit the release list to attributes the applications need, and record the purpose for each one.
- Access controls: Use group-based access in authentik so that only staff with a legitimate educational interest reach applications that hold student data. The regulation expects reasonable technological controls on school official access.
- Disclosure records: Ask whether attribute sharing with downstream applications, and the authentik logs that show it, must be recorded and kept for as long as the related records exist.
- Partner roles: If a partner administers the source, confirm in writing the direct control, use limits and redisclosure terms that apply to that partner.
Ask counsel to confirm the attribute list, the access groups and the log retention settings, and store that sign-off with the deployment record.
Attribute and identifier mapping between Shibboleth and authentik
This table compares each Shibboleth attribute with the authentik user field it populates, the purpose of that mapping, and who confirms it. Rows marked as team decisions need agreement between identity, legal and application owners before the source goes live, while rows that follow the Shibboleth guide are configuration steps to verify against your own IdP.
| Attribute or identifier | authentik user field and purpose | Decision or guide step, and who confirms |
|---|---|---|
| Stable unique identifier (for example, eduPersonPrincipalName or a persistent NameID) | Used to correlate the Shibboleth login with an existing authentik user. Choose one identifier and do not change it later, because a reissued or reassigned value creates a second account. | Decision. Identity team and the Shibboleth IdP owner agree which value is persistent for your campus, and confirm it with the IdP attribute resolver configuration. |
| Persistent NameID format | Stored as the source identifier so logins stay linked even if usernames change. | Decision. Confirm the NameID format the IdP sends and whether it is persistent or transient. |
| Email address (for example, mail) | Mapped to the authentik user email field. Used for notifications and, if enabled, for matching to existing accounts. | Guide step for the attribute name. Confirm with the IdP owner that the released value is the institutional address and is not shared or aliased. |
| Display name (for example, displayName or cn) | Mapped to the authentik user name field for display in the user interface and audit records. | Guide step for the attribute name. Confirm the IdP releases it, since some campuses withhold it by default. |
| Username (for example, uid) | Optional mapping to the authentik username. Keep it only if it is stable and unique, because users may later rename it in the directory. | Decision. Identity team decides whether usernames are used at all, or only the persistent identifier is used. |
| Affiliation or group claims (for example, eduPersonAffiliation or eduPersonEntitlement) | Mapped as attributes or used in property mappings to assign authentik groups and access policies. | Decision. Application owners list which values grant access, and the IdP owner confirms which values are released to authentik. |
| Attributes that should not be released (for example, national identifiers, date of birth, student number or health or grade data) | Not mapped to authentik and not released by the IdP. Limiting the release keeps the data outside the authentik database. | Decision. Privacy or records officer and the IdP owner approve the release list. FERPA may apply to education records, so confirm the release basis with counsel. |
Enrollment, linking and first-login decisions
The first federated login from Shibboleth either creates a new authentik user through enrollment or links the assertion to an account that already exists, and you need to decide which path applies before the source goes live. In authentik's SAML source, the identifier used to match a returning user is set in the source's user matching configuration, and it must be an attribute that Shibboleth releases consistently for the same person over time. A stable, opaque identifier such as the persistent eduPersonTargetedID or a campus-issued unique identifier fits this role. Confirm with your identity team which attributes your Shibboleth IdP releases to authentik and whether each one is guaranteed not to be reassigned to another person.
Avoid matching on a mutable attribute such as email address. Email addresses change when people marry, change names, or move between departments, and they can be recycled after a graduate leaves. If authentik matches on email, a changed address creates a duplicate account that the person cannot reach their old permissions through, and a reassigned address can silently attach one person's identity to another person's account. Decide who may enroll as well: the enrollment flow should be bound to the source only for affiliations you have approved, such as current students or staff, and the attribute check that enforces this belongs in a policy rather than in the IdP's release rules alone.
Test the existing-account case before any real user signs in. Create a local test user, then a directory-backed user with a known identifier, and attempt a federated login from a test Shibboleth account that carries the same identifier. Confirm that authentik links to the expected account, that group membership and attributes survive the link, and that a test account with the same email but a different identifier does not link. Record the result for each case, because the linking behavior is what auditors and your own incident responders will ask about first.
Security controls for federated university logins
A Shibboleth source gives university users a route into authentik, so every control on that route matters. The cards below cover what authentik should trust, what it should accept from that trust, and how the admin path and logs hold up if the federation is misconfigured.
Restrict trusted IdP entity IDs
Configure the SAML source to accept assertions only from the Shibboleth IdP entity ID your institution operates, and confirm that ID matches the one in the metadata you imported. Check that no other federation member can sign in through the source by default. Review the source list after every metadata change, because a broad metadata feed can add trust you did not intend.
Validate signing certificates and metadata
Import the IdP signing certificate through a verified channel, such as your identity team's published metadata, and record who approved it. Plan a dated process for certificate rollover, because an expired or unexpected certificate breaks logins or hides a substitution. Confirm how often the metadata is refreshed and who is alerted when it changes.
Release only required attributes
Map only the attributes each application needs, such as a scoped identifier, an affiliation value or a role, and drop the rest in property mappings. Ask the university which attributes its Shibboleth release policy will send and confirm which ones are personal data under your own policy. Use one mapping per application so a broad release to one app does not reach all of them.
Control enrollment for unknown users
Decide whether a federated user who is not already in authentik may create an account. Disable self-enrollment for the source unless it is intended, and use an approval step or a pre-created user match when it is. Test with an account that the university has not provisioned to confirm that the flow stops where you expect.
Protect the authentik admin path
Keep at least one local administrator account that does not depend on the Shibboleth source, and protect it with a hardware key or TOTP. Do not let a federated login gain admin rights through group mapping without a documented review. Confirm the recovery route if the university IdP is unavailable during an incident.
Log federated logins and changes
Record each federated sign-in, source configuration change and mapping change, and forward those events to the team that reviews access. Confirm that the logs show the source name, the entity ID and the user identifier, since those fields are needed for an investigation. Note that MFA on the Shibboleth side is the upstream IdP's responsibility, so confirm with the university what second factor it enforces.
Questions buyers ask before connecting Shibboleth to authentik
What does connecting Shibboleth to authentik cost, and who gets paid for what?
The cost comes from the work, not from a published price. A partner quote follows from a written scope, and the main cost drivers are the number of applications that will sign in through authentik, the number of attribute changes you need on the Shibboleth side, and how much testing the scope includes. Costs fall into two groups. The one-time work covers metadata exchange, the SAML source setup, attribute mapping, enrollment flow design and test sign-ins. The recurring costs cover running authentik, applying security releases and handling changes to the IdP later. Ask any provider to split the quote into these parts and to state who edits the Shibboleth configuration, since that work sits with your university identity team. DeployOpen does not publish a price list.
How long does a Shibboleth source setup take?
Duration depends on how quickly your identity team can change the Shibboleth IdP and release attributes, and on how many applications sit behind authentik. The technical steps are short when the IdP team is available: exchange SAML metadata, create the SAML source in authentik, map the attributes that identify users, and test sign-in with a pilot group. Delays usually come from change approval windows on the IdP, disagreement about which attributes to release, and enrollment rules that need review by the registrar or security office. Ask for a timeline that lists each dependency on your side, and confirm the change windows for the production IdP before work starts.
What does the university team need to provide before the work starts?
Three things unlock the work. First, administrative access or a named contact who can change the Shibboleth IdP configuration, including the relying party entry for authentik and the attribute resolver. Second, the IdP metadata file and a test or staging IdP if one exists, so the source can be verified before production. Third, decisions on attribute release: which attributes authentik receives (for example, a stable user identifier, email, display name and affiliation), which values are allowed to create accounts, and which must be left out. Also provide the list of applications that will use authentik, their required claims or attributes, and the owner who approves changes to the release policy.
Can an internal team connect Shibboleth to authentik without a partner?
Yes, an internal team can do it if it has the skills and time. The work needs someone who understands SAML concepts such as entity IDs, signing certificates, assertion consumer endpoints and attribute names; someone who can operate the Shibboleth IdP and its attribute resolver; and someone who runs authentik, including its flows, policies and PostgreSQL-backed deployment. Most teams underestimate testing, which should cover first login, returning users, users missing an expected attribute, logout and recovery. Check the authentik Shibboleth source documentation before you start, and decide who will own the configuration after the first go-live, because a source that works today can break after an IdP change.
Is the authentik Open Source edition enough for a Shibboleth source?
The Open Source edition covers the core SAML source capability that this integration depends on, but you should confirm the feature list against the current pricing page before deciding. The page lists Open Source as free with community support through Discord, and it lists the enterprise-only features separately. At the time of writing those include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions above a stated level. If your university needs audit logging for records access reviews or contractual support with response commitments, those requirements may point to an enterprise subscription. Compare your requirements with the authentik pricing page and get the edition confirmed in writing.
What records compliance obligations apply to student data in this setup?
If your institution receives federal education funds, FERPA applies to student education records, and the identity layer can be part of how those records are accessed. FERPA regulations at 34 CFR Part 99 require institutions to limit access to school officials with legitimate educational interests, using reasonable methods such as technological access controls, and to keep a record of disclosures of personally identifiable information. A contractor that handles records must operate under the institution's direct control and follow redisclosure limits. In practice this means you should define which attributes flow into authentik, restrict who can administer the source, log access and changes, and document the access model. Check the eCFR text of 34 CFR Part 99 and involve your privacy office and legal counsel, since DeployOpen prepares controls and evidence but does not issue compliance determinations.
Which attributes should authentik accept from the Shibboleth IdP?
Accept only the attributes that authentik needs to identify, provision and authorize users, and ask the IdP team to release them under the institution's attribute release policy. A stable, non-reassignable identifier should be the primary key, because email addresses and display names change. Affiliation or entitlement values can drive group membership, but each mapped value should have a named owner and a documented purpose. Attributes that carry sensitive student information, such as grades or detailed enrollment data, rarely belong in an identity provider handoff and should be excluded unless a specific application requires them. Record each decision, because auditors and records officers will ask why each attribute was released and to which applications.
What breaks most often after a Shibboleth source goes live?
The most common failures involve certificates, attribute names and changes made on the IdP side without notice. Signing certificates expire or rotate, and the source stops validating assertions until the new metadata is imported. An attribute renamed or removed in the IdP resolver can leave users unable to sign in or create duplicate accounts if the matching rules rely on email alone. Enrollment flows can also misbehave for users who lack an expected attribute. Plan monitoring on authentik logs for failed assertions, agree on a change process that reaches both teams, and schedule a test sign-in after every IdP change. Confirm with your IdP vendor or operator how certificate rollover is announced.
What FERPA and GLBA mean for student identity data
Whether FERPA applies to your authentik deployment depends on whether your institution receives funds under a program administered by the US Secretary of Education, since the rule in 34 CFR Part 99 covers any educational agency or institution that does. If it does, the Shibboleth source becomes a path into education records, because the attributes released at login (such as student ID, email, program or enrollment status) can be personally identifiable information. A contractor such as DeployOpen can handle those records as a school official only when it performs a service the institution would otherwise use employees for, stays under the institution's direct control for the use and maintenance of the records, and honors the redisclosure limits. Confirm those conditions in the statement of work and the data processing terms before any attribute is mapped.
FERPA also expects the institution to limit access by legitimate educational interest and to keep a record of each request and disclosure. In practice, this means your authentik role model, group mappings and attribute release should be designed so that only the staff and applications that need a given attribute can see it. Ask whether the access logs authentik produces can be retained for as long as the institution keeps the records, and who is responsible for answering a student's inspection request within the period the rule sets. Title IV institutions also agree to the GLBA Safeguards Rule, which requires multi-factor authentication for anyone accessing an information system. If your Shibboleth IdP does not enforce MFA, plan that control in authentik or your IdP before the source goes live.
DeployOpen does not provide legal advice, and it does not issue certifications or compliance attestations. Your institution's counsel and compliance office should confirm which regulations apply to your organization, including whether FERPA, the GLBA Safeguards Rule, or other rules such as the COPPA Rule apply to the populations you serve. The FSA Electronic Announcement GENERAL-23-09 describes how the Department of Education examines GLBA compliance, which is useful background for that conversation. Bring the attribute list, the retention plan and the MFA design to that review so the implementation decisions and the legal reading are made together.
Failure points that surface after go-live
The Shibboleth source usually works on the first test login and then fails later, when metadata or certificates change, when attributes shift, or when clocks drift. These four failure points share one pattern: each depends on a value that was correct at setup and was never rechecked.
Metadata expiry and certificate rotation
The SAML source trusts the Shibboleth IdP metadata and signing certificate you imported at setup. When the IdP rotates its signing key or the metadata is refreshed, assertions signed with the new key fail validation in authentik and users see sign-in errors that look unrelated to the source. Ask the university identity team for its rotation schedule and who notifies you, and confirm how you will re-import metadata before the old certificate expires. The metadata you imported is a snapshot, not a live trust relationship.
Attribute release gaps
Shibboleth releases only the attributes the federation and the IdP's attribute release policy allow for your service. If the username, email or affiliation attribute that your authentik property mappings expect is not released, the account is created without required fields, enrollment stalls, or a user lands with a partial profile. Check the attribute list in your metadata agreement against the mappings you configured, and test with a real account from each user population, such as staff, students and alumni. The gap usually appears only for one user group, so test more than one.
Clock skew and assertion validity
SAML assertions carry validity windows, and the IdP and authentik must agree on the current time within those windows. Clock drift on either side, or on a proxy or load balancer that handles the assertion, produces errors that appear intermittent, often only for some users or only at certain hours. Confirm that the authentik hosts and the IdP both synchronize time through NTP, and when an assertion is rejected, compare its issue time with the server clock before changing settings. Treat time errors as an infrastructure fault first.
Enrollment loops and duplicate accounts
A federated login can create a new authentik user when the identifier it arrives with does not match an existing account, such as a local account created earlier for the same person. The result is a duplicate account, a user sent back to enrollment repeatedly, or access granted to the wrong record. Decide before go-live which attribute identifies a person, how existing local accounts are linked, and who handles exceptions. Test an account that already exists locally, since that case is the most common source of duplicates.
Common Shibboleth source errors and how to fix them
This table pairs the failures teams most often hit when a Shibboleth IdP feeds authentik over SAML with the likely cause and first fix for each. Confirm the exact error text against the authentik logs before acting on a row, because the same symptom can come from more than one cause. Most problems trace back to metadata, signing certificates, released attributes or the username attribute.
| Symptom | Likely cause | Fix |
|---|---|---|
| Login fails after the IdP changed its signing certificate or endpoints | The metadata imported into the authentik SAML source is stale or was pasted from an invalid or partial file | Re-fetch the current metadata from your Shibboleth IdP, confirm the entity ID and SSO endpoint match, and re-import it into the source. Check the logs for the metadata parse error text. |
| Assertion rejected with a signature validation error | The signing certificate in authentik does not match the key the IdP uses to sign assertions, or the IdP signed the response but not the assertion as expected | Compare the certificate in the source with the IdP signing certificate, replace it if they differ, and confirm with your IdP operator which signing settings are in use. Do not disable signature checks to get a login working. |
| Enrollment fails or the new user record is incomplete | The IdP does not release the attributes authentik's enrollment or property mappings require, such as the email or name attributes | Ask the IdP operator to release the required attributes to this service provider under your attribute release policy, then map the received attribute names in the source's property mappings. Test with a user who has the attribute populated. |
| Duplicate accounts appear for the same person | The username attribute chosen for matching changes over time, is reassigned, or differs in case or format between sessions | Pick a stable identifier that the IdP releases consistently, such as a persistent identifier, and set it as the user matching attribute. Review and merge duplicates before enabling new enrollment for the source. |
| Existing users are locked out after an IdP change | The entity ID, attribute names or user identifiers changed on the IdP side, so authentik no longer matches those users to their accounts | Restore the previous identifier mapping on the IdP side if possible, or update the matching rule in authentik to the new value. Confirm with a test account before reopening access to all users, and keep a local administrator path available. |
Testing the source before the university rolls it out
Test the Shibboleth source with a pilot group that covers every affiliation pattern the university will see before any campus-wide release. Pick pilot accounts from several faculties, staff, a student population, an affiliate or visitor account, and at least one account with an unusual combination of affiliation values. For each account, record what the Shibboleth IdP asserts, what authentik stores on the user after first login, and which group or policy decides the enrollment path. Confirm the exact attribute names and value formats with the university's Shibboleth administrators, since the SAML source depends on them and the mapping in authentik has to match what the IdP releases. Keep the test log with the account, the timestamp, the assertion version and the result, because this log becomes evidence for the change record.
Run a negative test with an attribute the university has not released to the service. Use a test account whose attribute release does not include the field your authentik policy depends on, and confirm that the login is refused or routed to the intended fallback flow rather than granted access by default. Then test a missing or empty value for the attribute used to identify the user, since a mapping that accepts a blank identifier can create duplicate or ambiguous accounts. Finally, rotate the IdP signing certificate in a test tenant or staging instance, update the metadata on the authentik side, and confirm that sign-in still works and that the old certificate is rejected once removed. Record the metadata URL or file, its validity dates and the person who approved the change, so the rotation steps are repeatable.
Hand the tested configuration to the operations team as a short set of runbooks: the source settings and their owners, the attribute mapping table, the pilot test scripts, the metadata rotation procedure and the escalation contact at the university. Backups, upgrades and log forwarding for the authentik deployment are covered on the authentik operations and upgrades pages, so the runbook should reference those procedures rather than repeat them. Ask the university to confirm in writing who owns attribute release changes, because a silent change on their side is the most common cause of a sudden lockout. Agree how often the negative tests and certificate rotation will be repeated, and assign the person who signs off each repetition.
Rolling out to all users in phases
A phased rollout moves Shibboleth sign-in from a small pilot group to every user who needs it, with a clear check before each widening step. Local authentik logins stay available at every phase so a fault in federation never locks out administrators.
Confirm the pilot group and local break-glass access
Select a small pilot group of users whose Shibboleth accounts have the attributes authentik needs, and agree the group with the identity owner and the application owner. Before enabling the source for anyone, confirm that at least two named administrators can still sign in with local authentik accounts and that their credentials and MFA work. The step is done when the pilot list is signed off and a local login test has passed for each break-glass account.
Enable the source for the pilot group only
Configure the SAML source in authentik and restrict it to the pilot group through a policy or source binding, so other users keep their existing login path. Pilot users sign in through the Shibboleth button, and the team checks that enrollment, attribute mapping and group membership produce the expected user records. The step closes when each pilot user has signed in at least once and the records match the attribute release agreed with the identity owner.
Run one application end to end
Choose one application that the pilot group uses and connect it to authentik with the authorization it needs, keeping the application's own login available for fallback. Test the full path, including logout, session timeout and the application's role or group checks based on the released attributes. The step is complete when the application's owner confirms that access is granted and denied correctly for the pilot users.
Apply the go or no-go check
Review the pilot results with the identity owner, the application owner and the security lead against written criteria agreed before the pilot started, such as successful sign-ins, correct authorization and no unexplained account creation. Record a go decision only if every criterion passes and every open defect has an owner and a fix plan. If any criterion fails, the decision is no-go and the rollout stays at the current phase until the cause is found and retested.
Widen to remaining applications and user groups
Add further applications and user groups in batches, applying the same test and go or no-go check to each batch before the next one starts. Keep the list of enabled applications and the group bindings under version control or change records so every expansion is traceable. The step produces a documented coverage map showing which applications and groups use Shibboleth sign-in and which still use local or other login methods.
Switch the default login path with a tested rollback
Once all intended groups are covered, make the Shibboleth source the default login option for the users in scope, while leaving local accounts and the break-glass administrators unchanged. Document how to disable the source binding or restore the previous login path, and rehearse that rollback in a non-production environment. The step is done when the rollback has been rehearsed and the operations team has confirmed it can carry it out without relying on a user who depends on the failing login path.
Hand over monitoring and the rollback runbook
Transfer the running configuration, the coverage map, the pilot records and the rollback runbook to the team that will operate authentik, and confirm that failed SAML sign-ins and enrollment errors are visible in the logs they monitor. Agree with the identity owner who reviews federation errors and how changes to the Shibboleth metadata or released attributes are handled. The step closes when the operating team has accepted the handover in writing and has run one planned failure and recovery.
How DeployOpen scopes and delivers a Shibboleth source integration
DeployOpen plans, builds, documents and hands over Shibboleth IdP as a SAML source in authentik inside your own infrastructure. Each engagement starts with a written scope that fixes the attributes, enrollment rules and test cases before any configuration changes. Ongoing support and upgrades are available as a retainer after handover.
How we scope
- Inventory the Shibboleth IdP version, metadata location and the SAML entity ID authentik will trust.
- Agree in writing which attributes the university releases, and which authentik user fields they map to.
- Define enrollment behavior for first-time federated users, including whether accounts are created or matched to existing ones.
How we build
- Configure the authentik SAML source from the agreed metadata exchange and verify signing certificates before go-live.
- Build property mappings and group handling against sample attributes released by a test user set.
- Test sign-in, failed sign-in, logout and attribute changes in a staging authentik instance before any production cutover.
How we hand over
- Deliver a configuration record covering source settings, mappings, certificates, enrollment flow and rollback steps.
- Document the metadata renewal process, including who receives certificate expiry notices and how to replace the signing certificate.
- Walk your team through the test cases so they can repeat sign-in and attribute checks after future changes.
How we support
- Offer ongoing support for the source, including authentik version upgrades and Shibboleth metadata changes, as a retainer.
- Review attribute release and access logs when the university changes its release policy or adds new applications.
- Re-run the agreed test cases after each authentik upgrade before the change is approved for production.
