Migrate from Apereo CAS to authentik

Migrate from Apereo CAS to authentik without a single cutover day

authentik has no native CAS protocol, so the usual path is to federate your existing CAS server into authentik as an OpenID Connect source through the cas-server-support-oidc module, then move each CAS-protocol application to an OIDC or SAML provider on its own schedule. Your CAS server stays in place as the upstream login point while applications are switched over one at a time, so no single day has to carry every service definition at once. The CAS server remains the login authority during the transition, which is what makes the move staged rather than a flag day. The authentik Apereo CAS source documentation describes the source setup you will test first.

The effort depends on a short list of facts about your estate: how many CAS service definitions exist, which of them are still active, which ones use CAS attribute release or proxy tickets, and how many applications can change their own login configuration without a vendor patch. Each application type needs its own decision, since some will accept OIDC directly, some need SAML, and some are legacy systems that cannot change at all and may need a different path. Confirm with your directory team where users and attributes are authoritative, because attribute release from CAS must map cleanly to the claims or assertions each new provider expects. This work is fixed-scope. DeployOpen agrees the inventory of applications, the target protocol for each one, the attribute mapping, the test plan and the cutover order in writing before build starts, and a quote follows from that written scope. Ask any partner to produce that inventory and a per-application decision list first, because it is the input that determines both the cost and the sequence of the cutover.

What maps cleanly from CAS to authentik and what does not

This table compares the main CAS building blocks with their authentik counterparts, so you can see which parts carry over directly and which need redesign. Read the right-hand column as the work you should plan for, and confirm any custom overlay, web flow or handler logic against your own deployment before cutover.

Capability	Apereo CAS	authentik
Application protocol	CAS protocol service tickets (ST) validated by applications	No native CAS protocol. Applications move to OIDC or SAML providers, or CAS connects through an OIDC module during cutover
Service registry	Service registry entries matching service URLs and allowed attributes	Applications bound to OAuth2/OIDC or SAML providers with redirect URIs or entity IDs
Attribute release	Attribute release policies filtering what each service receives	Property mappings on each provider define the claims or SAML attributes released
Authentication handlers	Handlers for LDAP, JDBC, RADIUS, X.509 and similar methods	Sources and authentication stages in flows, with password and MFA stages; confirm each handler has an equivalent
Login and policy logic	Custom web flows and Spring configuration in the CAS overlay	Flows and policies; custom overlay logic usually needs redesign and should be reviewed line by line
Single logout	Back-channel logout to registered services	Logout behavior depends on provider type; confirm each application supports the logout method you need
Backing identity store	Often LDAP or a database accessed through CAS handlers	Users stored in PostgreSQL, synchronized from LDAP or other sources; confirm attribute and password hash compatibility
Custom CAS overlay code	Local Java modules, JSP views and custom handlers	No direct equivalent; review each customization and confirm whether it is needed in authentik

Documented import paths when you migrate from Apereo CAS

authentik does not speak the CAS protocol natively, so a CAS migration is really a set of routes: one for the CAS server itself during cutover, and one per application depending on how it authenticates today. Each route below covers a different part of the move and leaves different work to your team.

authentik Apereo CAS source

This route connects authentik to Apereo CAS through the cas-server-support-oidc module's OpenID Connect provider, so CAS can act as an upstream source while users and applications move. It is the bridge for the cutover period, not a permanent design. Your team still owns the CAS-side module version, the client registration on the CAS server, and how user identifiers and attributes map between the two systems. Confirm each of these with the CAS and module vendor documentation before you build the source.

OIDC provider for re-pointed apps

Applications that can accept OpenID Connect redirects can be moved to an authentik OAuth2/OIDC provider. Each application needs its own client registration, redirect URIs, scopes and claims, so the work is per application rather than a single server change. Check how each app reads the subject and email claims, because a changed identifier can create duplicate accounts. Plan a test login for every application before its cutover date.

SAML provider for legacy service providers

Service providers that only support SAML, which is common for older campus and vendor applications, can be re-pointed to an authentik SAML provider. Your team must exchange metadata, agree on entity IDs and signing certificates, and confirm the NameID format each service provider expects. Attribute release is the usual gap: CAS attribute release rules must be rebuilt as property mappings in authentik, and each mapping should be tested against the application's actual requirements.

LDAP provider for directory binds

Applications that bind to a directory rather than redirect to a login page can be served by authentik's LDAP provider. This route requires a decision on base DN, attribute names and how bind credentials are managed, since these are often hard-coded in the application. Confirm which LDAP features your applications depend on against the current authentik documentation, because the provider does not cover every directory operation. Applications that bind directly to the CAS back end may need reconfiguration.

Proxy provider for unsupported apps

Some applications, often older campus tools or internal web apps, cannot speak OIDC or SAML at all. A proxy provider places authentik in front of them through a reverse proxy, so the application trusts the identity headers authentik sends. Your team must control the reverse proxy path, prevent direct access that bypasses authentik, and test session expiry and logout. Each proxied application needs its own review of how it handles the forwarded user identity.

How CAS-protocol applications move to OIDC or SAML

Start by inventorying every CAS service and assigning each one a target protocol, OIDC or SAML, based on what the application itself supports. CAS services are usually registered in the CAS service registry with a service URL pattern, and that inventory is the starting point: record the service identifier, the callback or return URL, the attributes the application reads, and whether it expects single logout. Some applications support OIDC or SAML natively, others only accept a CAS ticket and need a plugin or a change in their authentication module. Confirm each application's supported protocols with its vendor or its own documentation before you choose, because an application's capabilities decide the protocol, not the other way around.

Moving an application changes several things it stores or assumes. On the authentik side you create an OAuth2/OIDC or SAML provider and an application entry, with new client credentials or SAML metadata. On the application side, the owning team usually has to update the registered redirect URIs or the SAML entity ID, change the login and logout endpoints, and confirm how it reads the user identifier. CAS commonly returns a username, while authentik's OIDC provider sends the claims you map, so the sub or a chosen claim such as preferred_username may not match the value the application already holds for each account. A mismatch can create duplicate accounts or lock users out, so test the identifier mapping with a real account before cutover. Logout behavior also differs, and some applications will keep a local session after the identity provider session ends.

Some legacy applications need changes that only their owning team can make, such as editing a configuration file, a database row that stores the CAS-issued identifier, or a plugin that calls CAS directly for service tickets. Plan these changes with the application owners before cutover and ask them to confirm a test login, logout and account match in a non-production copy. Keep the CAS service registration in place until each application has been verified on its new protocol, and record the owner, target protocol and verification date for every service so the retirement of CAS is driven by evidence rather than by the migration calendar.

Attribute release for OIDC and SAML applications

In authentik, an OIDC provider issues tokens whose contents are shaped by scope mappings and property mappings. Scopes such as openid, profile, email and groups determine which claims an application may request, while property mappings read values from the user object or its directory source and place them in claims. Start from what each relying party reads today in its CAS service definition, then map each attribute to the claim name that application expects.

Scope boundaries: Limit each application to the scopes it requests, so a client that asks only for profile does not receive fields it never uses.
Claim names: Match claim names exactly to what the application reads, including letter case and the format of multi-valued claims such as group lists.
Source attributes: Trace each claim back to its directory source, such as an LDAP attribute, so the origin of every value is known when a user record changes.
Token lifetime: Confirm how long issued tokens remain valid, because a token carries the claim values it was issued with until it expires.
Client type: Record whether each client is confidential or public, since that determines how secrets and redirect URIs are handled.

Decode a sample token from a test login and compare its claims with the application owner's written list before enabling production access.

CAS releases attributes through service-level policies, which are often defined per registered service or by a pattern that matches several applications. Those rules do not carry over automatically. Each rule needs to be read, expanded to the applications it covers, and rebuilt as a per-application mapping in authentik. Done this way, an application receives only what its own rule granted and nothing from a broader pattern that happened to match it.

Inventory the service registry: Export every registered service and its release rules, including any that use wildcard or regular expression matching.
Expand broad rules: A pattern that covers several services becomes one mapping per application, so each receives only the attributes it needs.
Map attribute names: Record the directory attribute behind each CAS attribute and the name the application expects to receive.
Retire unused releases: Services that no longer exist, or that read no attributes, should not receive a new mapping.
Keep a crosswalk: A table linking each CAS rule, its authentik mapping and the application owner becomes the basis for testing and for later audit evidence.

*Illustrative example:* a pattern that releases mail to every service under one domain may cover three applications, and only one of them may need the attribute. Compare the crosswalk with the live CAS configuration before cutover so no application loses an attribute without notice.

Migrate from Apereo CAS to authentik in five phases

This sequence moves CAS-protected applications onto authentik one at a time, keeping CAS available as an upstream source until each application is proven, so the cutover carries rollback options and the CAS server is retired only after its traffic has stopped.

Inventory CAS services and their consumers
Export every registered CAS service definition, including service URLs, attribute release rules, authentication policies and single logout settings. Ask each application owner to confirm how the application uses CAS, which user attributes it reads, and whether it relies on CAS proxy tickets or SAML-style responses. Your team provides the service owners and access to the CAS configuration; DeployOpen maps each service to a target protocol (OIDC or SAML) and flags attributes that need property mappings in authentik. This step is done when every service has an owner, a target protocol and a documented attribute list.
Pilot one low-risk application
Choose one application with a small user group, a non-critical role and a responsive owner. Configure CAS as an upstream source in authentik through the cas-server-support-oidc module's OpenID Connect provider, then create the pilot application's OIDC or SAML provider and application in authentik. Your team supplies test accounts and a window for user acceptance testing; DeployOpen configures the flow, the attribute mappings and the rollback path. The pilot is complete when test users sign in through authentik, the expected attributes arrive, and the owner signs off in writing.
Run a parallel period
Keep the CAS login path working for every application that has not yet cut over, while the pilot and early cutover applications authenticate through authentik. Monitor sign-in success rates, failed attribute reads, session behavior and helpdesk tickets for both paths. Your team owns user communication and the decision to widen access; DeployOpen assists with troubleshooting and tunes claim mappings. The parallel period ends when both paths are stable for the agreed set of applications and no open defects block the next group.
Cut over application by application
Move the remaining applications in groups, each with a documented change window, a named owner and written rollback criteria, such as a defined sign-in failure threshold, a missing required attribute or a broken integration that the owner cannot fix within the window. Update each application's configuration to point at authentik and verify logout, session timeout and attribute values against the test accounts. Your team approves each window and performs any application-side changes it controls; DeployOpen runs the configuration changes and rollback steps. A cutover group is closed only when its owners confirm success.
Validate attribute release and access rules
Before the last applications move, compare the attributes and group-based access rules that CAS released with what authentik provides through property mappings and policies. Confirm that role or affiliation data used for authorization matches the source of record your institution uses. Your team confirms the authoritative attribute definitions and any data handling requirements that apply to student or staff records; DeployOpen documents each mapping and runs the comparison tests. This step is done when every attribute difference is either fixed or accepted by the data owner in writing.
Decommission CAS after traffic stops
Keep CAS running in read-only or monitored mode until access logs show no remaining requests to its service endpoints for an interval your team sets with the application owners. Only then remove CAS service definitions, revoke its credentials, archive its logs and configuration under your retention policy, and shut down the server. Your team approves the decommissioning and handles records retention decisions; DeployOpen produces the traffic evidence, the final configuration export and the closure report. The phase is complete when the logs confirm no active use and the archive is verified.

What FERPA expects from the institution during the move

The migration itself touches education records. When authentik takes over sign-in, the directory attributes that CAS currently releases to applications (student ID, enrollment status, program, email, and similar fields) start flowing to new providers, and the access logs that CAS wrote will be replaced by authentik event logs. FERPA's regulations in 34 CFR Part 99 apply to any institution that receives funds under a program administered by the Secretary of Education (34 CFR 99.1), so the cutover is a change to how personally identifiable information is disclosed and recorded, not only an infrastructure change. Before the first application moves, confirm which attributes each CAS service receives today, which ones authentik will release through its property mappings, and whether any new application receives a field it did not get before.

If DeployOpen or another contractor performs this work, it may receive education records only as a school official under 34 CFR 99.31(a)(1)(i)(B). That means the service is one the institution would otherwise perform with its own employees, the institution keeps direct control over how the records are used and maintained, and the contractor follows the redisclosure limits in 99.33(a). The institution must also use reasonable access controls so that school officials, including administrators working in authentik, see only the records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). In practice, this means documenting which administrator roles can view user attributes, and removing project access when the cutover ends.

FERPA also requires the institution to keep a record of each disclosure of personally identifiable information, with the parties involved and their legitimate interests, for as long as the records are kept (34 CFR 99.32). Confirm that the migration plan defines where authentik's logs and the CAS log history will be retained, and who can answer a disclosure question later. Inspection requests have a deadline: the institution must respond within a reasonable period and not more than 45 days after receiving a request (34 CFR 99.10(b)), so the team should be able to locate a student's data across both systems during the parallel-run period. DeployOpen prepares controls, configuration records and evidence for the institution's review, but it does not issue compliance attestations or audit opinions. The institution decides its legal position with its counsel, and independent auditors make any formal assessment.

What drives cost and duration in a CAS migration

This table lists the factors that change the size of a CAS to authentik migration, why each one matters, and how to keep it manageable. Read each row as a question to answer during scoping, because the answers together determine the written scope and the quote. The main takeaway is that the number of service definitions, the protocol mix and the evidence FERPA requires usually matter more than the user count.

Driver	Why it matters	How to reduce it
Number of CAS service definitions	Each service definition is an application that needs a provider, redirect rules, and a cutover plan. Dormant or duplicate entries add work without adding value.	Inventory every service definition with its owner and last login date, then retire unused entries before migration starts.
Mix of CAS, SAML and OIDC consumers	CAS-protocol applications must move to OIDC or SAML, and each protocol needs its own configuration, testing and vendor-side changes.	Group applications by protocol and by the vendor's supported options, and move the simplest group first to build a repeatable pattern.
Custom CAS webflows or handlers	Custom Java code in the CAS server has no direct equivalent in authentik and must be redesigned as flows, policies or external logic.	Document each customization and its purpose, and remove features that no current application depends on before rebuilding them.
Attribute release complexity	Each application may receive a different set of attributes. Mapping these to authentik property mappings and scopes requires checking each consumer's expectations.	Build an attribute matrix per application with the exact claim or assertion names each application reads, and agree on it with application owners.
Identity store behind CAS	The source of users, such as LDAP, a database or a federated provider, determines how authentik connects to identities and whether passwords can carry over.	Confirm the store, its schema and whether password hashes can be reused before deciding the cutover sequence.
MFA requirements	Adding or changing second factors affects every application, and some clients may not support the factor you choose.	Decide the factor policy once in authentik flows and confirm which applications need step-up rules instead of blanket enforcement.
Number of users and environments	Larger populations and separate test, staging and production environments multiply validation and rollback work, though user count alone rarely sets the timeline.	Use a representative test group for pilots and keep environment parity so testing in staging reflects production.
FERPA or other framework evidence	FERPA requires institutions to show who accessed education records and why, and to limit school official access. Migration records, access logs and contractor terms must be ready for review.	Ask early which evidence the institution must keep, define log retention and access controls in scope, and confirm the requirements with the institution's counsel or compliance office.
Licensing edition	The open source edition is free according to the authentik pricing page. The Enterprise edition is listed at $5 per user per month billed annually plus $0.02 per external user per month, and features such as Microsoft Entra ID integration are Enterprise-only. Confirm which features your design needs before choosing an edition.	Map required features to editions during design, and ask for the quote to state the edition and any per-user license costs separately from implementation effort. The quote follows from the written scope.

What usually goes wrong when CAS is replaced and how to prevent it

CAS replacements tend to fail at the edges: applications that depended on CAS-specific behavior, attributes that no longer arrive, and infrastructure that stays alive after the cutover. Each card below names one failure mode and a check the team can run during the pilot and the parallel run before the CAS server is retired.

CAS-specific application behavior

Applications integrated over the CAS protocol rely on ticket validation, service tickets and sometimes single logout that do not map one-to-one onto OIDC or SAML. Authentik has no native CAS protocol, so the connection runs through the cas-server-support-oidc module's OpenID Connect provider during cutover. Inventory every application's validation call and logout behavior, then confirm in the pilot that each one completes login, logout and session expiry against the new client.

Attribute gaps after cutover

CAS service definitions often release attributes such as affiliation, student ID or course group that applications use for authorization. If the new OIDC or SAML client sends fewer or differently named claims, users may log in successfully but land with no access. Compare the attribute set each application receives from CAS today with the claims authentik releases through its property mappings, and verify with a test account in each application during the parallel run.

CAS left running with stale sessions

A CAS server kept online after cutover keeps issuing tickets and honoring existing ticket-granting cookies, so users may still authenticate through the old path and their sessions stay valid long after the new login is in place. This splits the audit trail between two systems. Decide a fixed date for disabling CAS logins, redirect the login URLs, and confirm in the parallel run that new sign-ins appear only in authentik's logs.

MFA protecting some paths only

Where CAS enforced a second factor for some services, the same requirement may not carry over to every OIDC or SAML client, or it may be applied to the web login but not to a legacy path that still reaches an application directly. Build a matrix of each application and each access route, including administrative and API paths, and check in the pilot that authentik's authentication flow challenges the same users on every route before cutover.

Unmapped service definitions

CAS service registry entries are sometimes incomplete, out of date or tied to applications nobody has used for months. Teams discover these only after decommissioning, when a department reports a broken tool. Export the service registry, match each entry to a live application and an owner, and mark entries with no owner as retire or migrate decisions before the parallel run starts.

Sessions that outlive cutover

Browser sessions, refresh tokens and application-local sessions created under CAS can persist after the switch, so a user may stay signed in to an application that no longer trusts the identity source. Set session lifetimes in authentik deliberately, define how applications end their own sessions, and test in the pilot that a user who signs out of authentik is also signed out of the migrated applications.

Questions buyers ask before moving from CAS to authentik

What does a CAS to authentik migration cost?

The cost is set by the written scope, not by a list price. DeployOpen does not publish prices, and a quote follows from the inventory of CAS-protected applications, the protocols each one needs, and the attribute and testing work involved. Cost components are the discovery and inventory work, the design of the OIDC chain and attribute release, the application cutovers, testing with your owners, and handover documentation. Most of this is one-time. Recurring cost is the authentik platform and your hosting, plus any support retainer you choose. If you are weighing the commercial authentik edition, the 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 separates one-time work from recurring items and states which applications are in and out of scope.

How long does moving from CAS to authentik take?

Duration depends on the drivers, not a fixed number. The main ones are how many CAS-protected applications exist and how many you can move without changing their code, whether each application speaks CAS, OIDC or SAML, how many attribute mappings need approval, how many owners must test, and how many change windows your academic calendar allows. A cutover that keeps CAS running as an upstream source for a period adds coordination time but lowers risk. Ask for a timeline that lists these drivers and the dates your institution must confirm, such as term start and freeze periods.

What must our institution provide before the migration starts?

The work depends on decisions only your institution can make. Prepare the following before the engagement starts:

A service inventory listing every CAS-protected application, its URL, its protocol and its owner
Named owners who can approve changes and test sign-in for each application
Test accounts covering student, staff, faculty and guest roles
Written approval for each attribute your applications will receive, with the data owner's name
Change windows that avoid enrollment, grading and exam periods
Access to the CAS configuration, the identity store behind it and the DNS and certificate processes you use

Missing owners or unapproved attributes are the most common reasons a cutover slips.

Can our own team migrate from CAS to authentik without a partner?

Yes, for a small estate with strong CAS knowledge, but the team needs specific skills. Small deployments with few applications can often be moved in-house if the team understands CAS service definitions and attribute release, can run authentik with Docker Compose or Kubernetes, and can configure OAuth2/OIDC and SAML providers. Larger estates benefit from an outside team for the inventory, the cutover plan and testing discipline. Whichever path you choose, confirm that someone on the team can operate PostgreSQL backups, read authentik logs and handle upgrades after go-live.

Can authentik import users directly from our CAS server?

Not directly from CAS itself. authentik has no native CAS protocol source. It connects to Apereo CAS through the cas-server-support-oidc module's OpenID Connect provider, which lets CAS act as an upstream login during cutover. User records still live in the identity store behind CAS, such as LDAP, a database or JDBC. Confirm which store holds your accounts, how passwords are stored and whether authentik can reach that store, because that path determines how users move. The authentik CAS source documentation describes the integration and is the right next read.

Does DeployOpen certify that our authentik deployment is FERPA compliant?

No. DeployOpen does not issue audit reports, attestations or certifications. It can prepare systems, access controls and evidence for your compliance review, such as documented access control design, logging and the record of which school officials have access. FERPA obligations fall on the institution, and the Department of Education's enforcement applies to the institution. Independent auditors and your institution's compliance office decide whether the deployment meets the requirements. Ask your counsel which contractor and access terms apply under 34 CFR 99.31 before any student record reaches the project.

How DeployOpen scopes and delivers a CAS to authentik migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including the cutover from Apereo CAS to authentik. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every CAS-protected application, its protocol, and how it reads user attributes today
Record which CAS service definitions need OIDC or SAML equivalents and which can be retired
Confirm the attribute release rules, user sources and MFA expectations each application depends on
Agree in writing the scope, deliverables, cutover approach and any retainer for ongoing support

How we build

Stand up authentik in your infrastructure and connect CAS through the cas-server-support-oidc module as a source
Recreate each application as an OIDC or SAML provider with property mappings matching the released attributes
Test each application login, logout and attribute value in a staging environment before any production change
Verify the CAS-to-authentik login chain under the failure and rollback paths agreed during scoping

How we hand over

Document every provider, source, mapping, flow and policy created during the migration in a written handover
Record the cutover order, rollback steps and the decommissioning checklist for the CAS server
Provide access logs and evidence of tested login paths that your access control and records reviewers can use
Walk your administrators through day-two tasks such as adding applications and changing attribute rules

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete
Plan authentik version upgrades against your own release calendar and the supported version policy
Review attribute release and application access after each change, so drift from the handover is caught early
Confirm with your team which support scope, response expectations and testing cadence the retainer should cover