midPoint for universities and education

Why midPoint for universities and education starts with identity lifecycles

A registrar or CIO whose accounts for students, staff, affiliates and alumni are created by hand in several places usually has no single answer to who holds access today. midPoint for universities and education centers on lifecycle rules driven by authoritative feeds, so the source system decides when an identity begins, changes, is suspended or ends, and midPoint carries that decision to every connected system. midPoint is an identity governance and administration platform written in Java and developed by Evolveum. Its repository is licensed under the European Union Public License (EUPL-1.2) with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition, so every line of midPoint code is published under open source licenses. The platform is deployed in the institution's own infrastructure, which keeps student and staff records under the institution's control.

The authoritative feeds at a university usually include the student information system, the HR system and an affiliation source such as SWITCH edu-ID where the institution uses it. Each feed emits different events, such as admission, enrollment change, contract start, leave or departure, and each event should map to a lifecycle state in midPoint. Decide before the build which system is authoritative for each attribute and each identity type, because a person who is an alumnus, a part-time staff member and an affiliate with a sponsor will otherwise receive conflicting rules. The Evolveum catalog lists a SWITCH edu-ID Affiliation connector and Grouper connectors maintained by Evolveum as supportable, while the Canvas LMS connector carries community support status. Confirm with the Evolveum connector documentation and your own source owners which versions and support status apply to each feed, and assign support ownership accordingly.

Login is a separate decision. midPoint is an identity management system and does not serve as an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. Its own user interface can authenticate against an external SSO service, but students and staff still sign in to campus applications through a login service you select and operate. Plan that service as its own project with its own owner, and check how it consumes the accounts and attributes that midPoint provisions, including attribute names and group claims. Ask the login product's vendor to confirm exactly which protocols it supports before you commit to a design that depends on them.

Start the project by writing a lifecycle matrix with one row for each identity type, source, event, affected target system and any approval or notification that must happen. Include the FERPA duties that shape it, since the institution must limit which school officials can reach education records and must keep a record of disclosures. Confirm with counsel and your privacy office which requirements apply, because FERPA obligations depend on whether your institution receives funds under a program administered by the US Secretary of Education. A matrix written this way also gives your team a test plan: each row becomes a scenario you can run in a non-production environment before any live account changes.

Which university requirements shape the midPoint build

This table maps federal requirements that often shape a midPoint build at a college or university to the roles, provisioning logs and access reviews each one affects. Read each row as a design input for the build team, and confirm how each rule applies to your institution with counsel and your compliance office.

Requirement	Source	What it means for the build
School official and legitimate educational interest	34 CFR 99.31(a)(1)(i)(B) and (a)(1)(ii)	Define roles by legitimate educational interest. Model contractor accounts as school officials only with direct institutional control and redisclosure limits. Review role scope regularly.
Record of access and disclosure	34 CFR 99.32	Retain provisioning and access logs that show who requested or received student information, their interest and the date. Keep these records as long as the underlying records are kept.
45-day inspection timeframe	34 CFR 99.10(b)	Keep student and parent record locations traceable through directory and HR data so that inspection requests can be fulfilled within 45 days of receipt. Test this with sample requests.
GLBA Safeguards Rule for Title IV participants	16 CFR 314.4(c)(5) and (j); FSA GENERAL-23-09	Require multi-factor authentication for anyone accessing information systems. Document the written information security program. Plan FTC notice for qualifying events.
Secretary's enforcement powers	34 CFR 99.67	Noncompliance can lead to withheld payments, cease and desist complaints or loss of funding eligibility. Provisioning evidence must be exportable and reviewable on demand.
Applicability to your institution	34 CFR 99.1; 16 CFR Part 314	FERPA applies where the institution receives funds under a program the Secretary administers. GLBA obligations follow Title IV participation. Confirm which rules apply before setting the build scope.

How student and staff lifecycles run from HR and SIS feeds in midPoint

The most important decision in a midPoint education deployment is which system is authoritative for each population. The student information system, the HR system, the admissions platform and any sponsorship process can each hold a record for the same person, and midPoint can only create, change or disable an account reliably when it knows which feed governs that attribute. Before building connectors, the institution should confirm, in writing, which feed owns identity attributes, enrollment or employment status, effective dates and organizational unit for applicants, students, staff, faculty, affiliates and alumni. Where two feeds disagree, the rule for resolving the conflict should be documented and tested, not left to whichever sync ran last.

Once the authoritative feed is fixed, lifecycle transitions follow from its records. A new applicant or hire record can create the identity, a status change can move it between lifecycle states, and an end date can disable access on the expected day. Role models then translate feed attributes into the access each population needs. The institution must decide whether roles are granted automatically from feed attributes, requested and approved, or both. The applicant-to-student transition is a useful test case: the team should decide whether the same identifier carries forward, when campus access begins, and which access an applicant should never receive before enrollment is confirmed.

Several common cases require explicit design choices. A staff member holding several appointments may need one identity with several assignments, or separate identities that are linked. The team must define which appointment drives the primary email address and what happens when one appointment ends while another remains active, so that access is not removed too broadly. Affiliates such as visiting researchers or contractors need a sponsor and an end date. For leave of absence, the institution should decide whether to suspend access, keep mail and storage, or disable everything. For alumni, it should decide which services remain available, for how long, and who approves them.

Role assignments should reflect a legitimate educational interest, so that school officials see only the education records their job requires. Under FERPA, the institution must use reasonable methods, such as access controls, to limit school officials to records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)), and it must keep a record of disclosures (34 CFR 99.32). In midPoint, that means mapping each role to a documented job function, testing sample accounts against the expected records, and reviewing role membership regularly. Whether FERPA applies to a given institution, and how it interacts with GDPR or other rules, should be confirmed with counsel. Connector support also varies: the Evolveum catalog lists a SWITCH edu-ID Affiliation connector and a Canvas LMS connector with community support status, so the support level for each should be confirmed before it is relied on.

Connectors, modules and settings that matter in higher education

A university midPoint build usually joins student and staff sources, federated identity services, learning platforms and governance controls. The cards below cover the connectors and settings that most often shape scope, and each one lists what to confirm about status and version before you commit to a design.

SWITCH edu-ID Affiliation connector

This connector in the Evolveum catalog is supportable and maintained by Evolveum, and it brings affiliation data from SWITCH edu-ID into midPoint for Swiss and other participating institutions. Affiliation values often drive which roles and resources a person receives, so map them to your role model before build starts. Confirm the connector version against your midPoint release, the edu-ID service agreement that governs your institution, and which affiliation attributes your federation actually publishes.

Grouper connectors and PostgreSQL JDBC

The Grouper connectors, including the JDBC variant for PostgreSQL, are catalog items maintained by Evolveum with supportable status. Grouper holds group and membership data that midPoint can turn into entitlements, so the design question is which group folders are authoritative and which are read only. Confirm the supported Grouper version, the database driver version your PostgreSQL server requires, and who owns group naming conventions on the Grouper side.

Canvas LMS connector

The Canvas LMS connector is maintained by Evolveum with community support status, which means your team carries more of the testing and troubleshooting than with a supportable connector. Course enrollments and account provisioning in Canvas depend on terms and sections defined outside midPoint, so agree those boundaries early. Confirm the Canvas API version your institution runs, the connector release that matches your midPoint version, and whether an Evolveum Product Support subscription covers the defects you expect to raise.

LDAP, Active Directory, Entra ID and SCIM targets

LDAP and Active Directory are the directory targets most universities already run, and the Evolveum docs document both alongside Microsoft Entra ID through the Graph API and SCIM2 targets. Decide which system is authoritative for each attribute and which accounts midPoint may create, disable or delete, because directory writes reach many downstream services. Confirm the connector status for each target in the catalog, the directory schema and service account permissions in your environment, and any SCIM server version your application vendors support.

CSV and DatabaseTable HR and SIS feeds

The CSV and DatabaseTable connectors are documented midPoint connectors that suit scheduled extracts from HR and student information systems when a live API is not available or not approved. Feed quality decides lifecycle accuracy, so define file naming, delimiter rules, expected row counts and a rejection path for malformed records before go live. Confirm with the data owners how often each extract runs, which fields are personal data under your privacy rules, and how the extract is transported and retained.

Role models, approvals and certification campaigns

Role models define which access a student, instructor or staff member receives from affiliation and organizational data, and midPoint can route requests for elevated access through approvals before provisioning. Access certification campaigns then ask owners to confirm that continuing access is still justified. Design these as one control set, because roles that are hard to explain make approvals and reviews unreliable. Confirm the midPoint release you plan to use, the approval workflow your governance board accepts, and how campaign evidence will be exported for auditors.

How SWITCH edu-ID, Grouper and Canvas connectors fit the build sequence

The build order matters more than the number of connectors. Start by confirming the HR and student information system extracts, because every downstream connector depends on the person records, affiliations, student status and identifiers those extracts provide. Agree the authoritative source for each attribute, the joiner, mover and leaver events, and how a person who is both staff and student is represented. Ask the registrar and HR owners to sign off on a sample extract before any target system is connected. A mismatch found at this stage costs far less than one found after provisioning has written accounts into a live target.

Next, build the directory connectors. LDAP and Active Directory give midPoint a baseline account store for staff and students, and they are where account and group decisions are tested first. midPoint uses the ConnId connector framework for these targets, so configuration patterns carry across connectors, but each target still has its own schema, service account rights and failure behavior. Confirm the service account permissions and the directory schema in writing with the directory owners before design freezes, and record which attributes midPoint is allowed to write.

Federation-related and group-based targets come after the directory layer. Evolveum lists a SWITCH edu-ID Affiliation connector and Grouper connectors, including a JDBC variant for PostgreSQL, as supportable. Grouper depends on memberships that already exist in the sources, so build it once the directory and affiliation data are stable. Decide early whether the JDBC variant matches your database standards. midPoint provisions affiliation and group data, but sign-in remains with your federation and identity services, so test the handoff between them rather than assuming it works.

Learning platforms come last. Evolveum lists the Canvas LMS connector with community support status, which changes the burden. Community status means your team carries more of the testing, troubleshooting and version management, and you should not assume the same support terms as for supportable connectors. Whichever connector you use, test each one against non-production copies of the target system, using sanitized student data. FERPA treats an outside party that receives education records as a school official only under defined conditions, and the institution must still record each disclosure, so log what each connector sends. Before design freezes, ask Evolveum to confirm the supported versions of every connector in the design.

Compliance drivers for a university identity platform

Each regime below changes a different part of the identity platform: who may see which records, how access is authenticated and logged, how long data is kept, and how interfaces are delivered. Which regimes apply depends on the institution's federal funding, location, student population and public status. DeployOpen prepares systems, controls and evidence for assessment, but the institution and its auditors decide which regimes apply and whether the evidence is sufficient.

FERPA access controls and disclosure logging

FERPA (34 CFR Part 99) requires institutions to limit school officials' access to education records to those with legitimate educational interests, and to record each disclosure of personally identifiable information with the parties involved and their interests. In midPoint for universities and education, this means role models and entitlements that map to academic roles, plus audit trails for provisioning changes that reach student records in directories and the learning management system. Check whether your connectors and audit logs show who received which record, and how long those logs are kept.

GLBA Safeguards obligations for Title IV

Institutions in the Title IV federal student aid programs agree in their Program Participation Agreement to follow the GLBA Safeguards Rule (16 CFR Part 314). The rule requires a written information security program, multi-factor authentication for anyone accessing any information system, and FTC notification within 30 days of discovering an event affecting at least 500 consumers. For a midPoint deployment, confirm that administrative consoles, connector service accounts and self-service logins all sit inside the MFA policy before the design is approved.

COPPA for data from children under 13

Where the institution or its programs collect personal information from children under 13, the COPPA Rule (16 CFR Part 312), amended on 22 April 2025, requires a written information security program with a designated coordinator, at least annual risk assessments, and a written retention policy with a deletion timeframe. Summer academies, K-12 partner accounts or outreach programs can create such records in midPoint. Confirm which object types hold child data and how deprovisioning removes that data from every downstream system.

GDPR for EU data subjects

GDPR (Regulation (EU) 2016/679) applies when the institution processes personal data of people in the EU, including applicants, exchange students and staff based in the EU. For an identity platform, this shapes the lawful basis for each attribute synced from HR and admissions, the minimization of attributes in connector mappings, and the location of any hosted component that receives personal data outside the EU. Ask the data protection officer to review attribute flows before connectors go live.

NIS2 scope and identity controls

NIS2 (Directive (EU) 2022/2555) sets cybersecurity obligations for entities in its covered sectors, and member states decide how it applies to each institution through national transposition. Whether a university is in scope depends on that national law and on the institution's activities. If it is, identity lifecycle controls, access reviews and incident handling for the identity platform become part of the required measures. Confirm scope with the national competent authority or counsel before defining midPoint controls.

Web accessibility under 28 CFR Part 35

Public institutions covered by Title II of the ADA must make their web content and mobile apps accessible under 28 CFR Part 35 Subpart H. Administrative interfaces and self-service pages in midPoint for universities and education, such as password reset, access request and profile screens, fall within that obligation when the public entity provides them. Ask the vendor for its conformance documentation, and test custom templates with assistive technology, since custom builds often change exactly those screens.

How a university midPoint rollout moves from pilot to production

This sequence takes a university from agreed identity sources to a midPoint service that provisions and reviews student and staff access under controls the registrar, HR and IT owners can evidence. Each step closes with a check that gates the next one. Ask for a phased schedule in the written scope before any work starts.

Discover authoritative sources and population definitions
The team inventories the systems that hold identity facts: the student information system, HR feed, existing LDAP or Active Directory, the LMS, and any federation or group services. Registrar and HR owners define who counts as a student, staff member, affiliate or leaver, and which source wins when records conflict. The owners also list the target systems that will receive accounts, such as SWITCH edu-ID or Grouper where the institution uses them, and Canvas LMS where it applies. The step closes with a signed source-of-truth matrix and population definitions that name a single owner for each attribute. Ask DeployOpen to confirm the connector support status for each target before design begins.
Design roles and policies with registrar, HR and IT owners
Working sessions turn the population definitions into a role model, lifecycle rules for joiners, movers and leavers, and approval paths for exceptions such as sponsored guest access. The design records which entitlements follow from enrollment status, appointment or department, and which need a manual approval. Access rules also cover FERPA-relevant handling of education records, including who may see which student attributes and how requests for access are logged. The step closes with an approved design document and a list of open decisions with named owners. Each policy should trace back to a source attribute so that reviewers can test it later.
Build a non-production environment with connectors to test targets
DeployOpen installs midPoint in a non-production environment inside the institution's infrastructure, using the PostgreSQL repository and the node layout agreed for the target size. The team configures ConnId connectors for the authoritative feeds and for test instances of each target system, then runs create, update and disable operations against synthetic identities. Failed operations, mapping errors and attribute mismatches are logged and fixed before any production credential is used. The step closes with a test log showing each connector completing the agreed lifecycle events, and with a documented rollback for the test environment. Confirm the exact midPoint release and Java version with the project before installation.
Pilot with one department before wider rollout
The team selects a pilot population, such as a single department with a defined set of staff and students, and runs real lifecycle events through midPoint for that group. Registrar or HR staff compare provisioned access with what the design says should exist, and the service desk records every ticket raised during the pilot. Issues are fixed in the design or configuration, then the pilot is repeated until results match the design. The step closes with a pilot report listing defects, decisions taken and the criteria used to approve a wider cutover. Expanding scope without a passed pilot is the most common way to create unexplained access changes.
Cut over in controlled stages with reconciliation
Production cutover proceeds in stages, moving one population or target at a time while the existing directories remain in service. For each stage, midPoint's view of accounts and entitlements is reconciled against the current LDAP, Active Directory or target system data, and differences are classified as expected changes, data defects or policy gaps. Owners sign off each difference before the next stage starts. The step closes with reconciliation reports for every stage and a documented decision on when the legacy process is retired. Ask for the cutover and rollback plan in the written scope, including who can halt a stage.
Set up access certification and audit evidence before the first campaign
Before the first access review, the team configures certification campaigns, reviewer assignments, escalation rules and the retention of decision records in midPoint. It also defines the evidence pack the institution will retain: role and policy versions, approval logs, provisioning and reconciliation reports, and records of access requests and disclosures. Control owners map these artifacts to the frameworks their auditors use, such as the Safeguards Rule requirements for multi-factor authentication and access control under GLBA. DeployOpen prepares the evidence and the controls; independent auditors judge them. The step closes when a test campaign produces a complete, reviewable evidence set that the owners have accepted.

Choosing a midPoint release for a multi-year university deployment

For a multi-year university deployment, the release decision depends mainly on how long each release receives support, and only second on the features it offers. midPoint 4.8 (Curie) is a long-term support release, supported until 17 October 2028. midPoint 4.10 (Braille) is a feature release supported until 26 November 2027. midPoint 4.9 support ends on 18 October 2026, so any institution running 4.9 needs a move to a supported release within the next year. midPoint 4.11 (Čapek) is planned as a feature release for 21 October 2026. Because the dates on the midPoint releases page can change, confirm the current status of each version there before you select one.

A long-term support release suits a program that expects to run the same identity platform through several academic years with few upgrades. A feature release gives access to newer capabilities, but its support window closes sooner, so the team will need another upgrade before the program's planned end. Map the expected go-live, the pilot period, and the years the institution plans to operate the service. Then compare those years against each release's support end date. Ask Evolveum or your implementation partner to confirm that the connectors your university needs, such as the SWITCH edu-ID Affiliation, Grouper and Canvas LMS connectors, are validated against the release you choose.

The Java requirements affect hosting decisions early. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported. For 4.10 and older releases, Java 21 is recommended and Java 17 is supported. Your university IT team should confirm which JDK builds its operating system images, container base images and patch process can provide, and whether those builds will still be maintained for the full support window. PostgreSQL is midPoint's native repository database, and midPoint recommends running it on a separate database server. Check the system requirements page for the PostgreSQL versions supported by your chosen release, and plan backups and high availability for that database from the start.

The academic calendar limits when an upgrade can happen. Identity changes touch enrollment, course access, library accounts, email and payroll-linked roles, so a failed upgrade during registration, the first week of term, grading or financial aid disbursement can have wide effects. Build a change calendar with blackout periods around these events, and reserve a rehearsal window in a non-production environment that uses a recent copy of the repository. Agree on a rollback decision point with the identity, service desk and registrar teams before the production window opens. Schedule the 4.9 exit and any move to 4.11 with these periods in mind, since the 4.9 end date falls in autumn 2026.

What a midPoint for universities and education project involves

What drives the cost of a university midPoint project?

The written scope drives most of the cost. The main factors are the number of authoritative sources (HR, student information system, directory), the target systems to connect, the complexity of roles and policies, and the approval flows that must be built. A quote follows from that scope, and most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. One-time costs cover design, build, connector configuration, testing and cutover. Recurring costs cover support, upgrades and any subscription you choose. Ask the quote to list each feed, connector and environment separately, state the testing assumptions, name what is excluded, and identify which costs recur. DeployOpen does not publish a price list.

Can a university build midPoint with its own staff?

Yes, if the team has the skills and time to own the project end to end. A typical university team needs an identity engineer who understands provisioning and role design, a directory or database administrator, an integration developer who can work with the HR and student systems, and a data owner in the registrar or HR office who can make policy decisions. Many institutions use a partner for the design and first build, then take over operations. The trade-off is staff time against delivery risk. Ask any partner for a written scope that separates design, build, testing, documentation and knowledge transfer, so your team can see what it would take on.

How long does a university midPoint project take?

Duration depends on the scope, the readiness of your data sources and your calendar. The number of feeds and target systems, the number of policy decisions still open, the number of environments, and the availability of test accounts and change windows all change the schedule. Academic calendar constraints, such as enrollment periods and term starts, often set the cutover window. DeployOpen agrees timelines in writing as part of the fixed scope, so ask for milestones tied to decisions and deliverables rather than a single end date. Ask which items could delay the plan, who owns each one, and what happens if a feed owner misses a date.

What must our institution provide before a midPoint project starts?

The institution supplies people, decisions and environments. Plan for named feed owners for HR, the student information system, and directories, who confirm data quality and change rules. Policy decisions are needed on who receives which access, how joiners, movers and leavers are handled, and who approves exceptions. You also need test accounts in non-production systems, access to vendor or tenant administration for each target system, and agreed change windows for production cutover. For student records, confirm with counsel how a contractor may receive education records. Under 34 CFR 99.31, a contractor can act as a school official only under specific conditions, including direct institutional control over use and maintenance of the records.

Does DeployOpen support a Canvas LMS or Grouper connector for midPoint?

The Evolveum catalog lists both, but their support status differs, so confirm it before scoping. The catalog lists a Canvas LMS connector maintained by Evolveum with community support status. It also lists Grouper connectors from Internet2, including a JDBC variant for PostgreSQL, which Evolveum maintains as supportable. A SWITCH edu-ID Affiliation connector is also listed. Ask for the connector version, the target system version, and the support status recorded in the catalog at the time of quoting. Your scope should state which connector features are in use, because a connector that works for provisioning may not cover every attribute or workflow you need.

What does ongoing support cover after a midPoint go-live?

Ongoing support can come from DeployOpen, from Evolveum, or from both, and they cover different things. DeployOpen offers retainers for support, upgrades and continuous testing, which you can scope to your environment and feeds. Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and separate Platform Subscriptions that add feature development and roadmap influence. Evolveum's subscriptions are sold separately from implementation work. Ask each provider what response times, exclusions and recurring fees apply, and who handles connector issues, midPoint upgrades and Java or PostgreSQL changes.

Which midPoint release should a university deploy?

Choose a release with a support end date that outlasts your planned upgrade cycle. According to the midPoint releases page, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028. Midpoint 4.10 (Braille) is a feature release supported until 26 November 2027, and 4.9 support ends on 18 October 2026. Midpoint 4.11 (Čapek) is planned for 21 October 2026. Evolveum recommends Java 25 for 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Confirm the current release table and your database and Java standards before you fix the target version in the scope.

How DeployOpen scopes and delivers midPoint for universities

DeployOpen plans, builds, documents and supports midPoint for universities and education inside your own infrastructure, with the student and staff identity lifecycle, connectors and records handling agreed in writing before work starts. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

The written scope names the student and staff populations, HR and LDAP sources, and the SWITCH edu-ID, Grouper and Canvas LMS connectors in use.
We confirm each connector's Evolveum support status before committing it to scope, since catalog status ranges from supportable to community.
Scope records how FERPA school official access, need-to-know limits and record-keeping obligations map to midPoint roles and audit logs.

How we build

We design lifecycle rules for joiners, movers and leavers from the registrar and HR feeds, then test them in a non-production environment.
Connector configuration for Grouper, Canvas LMS and LDAP is built and verified against documented attribute mappings and reconciliation results.
We set up PostgreSQL, the multi-node layout and the Java runtime for the midPoint release your institution selects, and document the version chosen.

How we hand over

Handover includes runbooks for provisioning failures, connector outages, access certification campaigns and midPoint task scheduling.
We deliver configuration as versioned artifacts, along with test cases showing lifecycle outcomes for each student and staff population.
Your staff receive operator training on the deployed roles, approvals and reports, with the scope of what remains in your team's hands stated in writing.

How we support

Ongoing support, upgrades and testing are available as retainers, and upgrade planning follows midPoint's supported version stops.
We can plan around Evolveum's Product Support or Platform Subscriptions, which you buy directly, and state where those contracts apply to your scope.
Retained support covers connector changes, such as updates to the Canvas LMS or edu-ID integrations, and reviews of data retention rules for records kept in midPoint.