← Back to scenarios Ministry of Education · SIIR · WSO2 IS · Azure AD

Student identity at national scale — building the backbone of Edulib

For the Romanian Ministry of Education's Edulib programme, we built the integration fabric that synchronizes student data from the national school information system into a federated identity layer — then into the classroom tools students actually use.

The scale of the problem

Hundreds of schools. Hundreds of thousands of student accounts. Teachers, principals, administrative staff — each with a role that determines what they can see and do in the platform. Every account has a lifecycle: it is created when the student enters the system, moved between groups as they progress through years and classes, linked to grades and attendance, and eventually retired. None of this is static. On an average weekday the system processes thousands of identity changes.

Identity at the core

WSO2 Identity Server handled user, group and organization modelling on the Edulib side. Azure Active Directory provisioned actual accounts students and teachers logged in with. The two had to stay consistent across the full lifecycle — create a user in SIIR, and within seconds both WSO2 IS and Azure AD reflect it. Assign the user to a group, and their permissions update in both. Retire the user, and both know. An inconsistency between the two is a user who can sign in but cannot do anything, or the reverse — the kind of problem a classroom teacher doesn't have time to debug.

The integration fabric

Eight integration interfaces consumed from ActiveMQ queues, each handling one part of the lifecycle — create user, assign group, manage grades, delete users, organization sync, role mapping. Queue-based transport meant that a temporary outage in Azure AD or WSO2 IS didn't lose events; they accumulated and drained when the backend returned. Each queue had its own dead-letter channel for what couldn't be processed even on retry. When the operator looked at the DLQ, every message was correlated — they could tell exactly which student registration had stalled and why.

The public surface — apiport.edu.ro

A subset of Edulib data had to be reachable by third parties — other ministries, educational software vendors, statistical agencies. For that we exposed a public REST API at apiport.edu.ro, built with WSO2 API Manager conventions: versioned contracts, OAuth2-based access control, per-consumer throttling. External systems didn't get direct access to the identity store; they got a governed, contract-first API surface that the Ministry could audit end-to-end.

Governance and audit

Organizations, roles and permissions were modelled separately on purpose. A school is an organization. A teacher is a user. The role that makes a user a principal at one school and a regular teacher at another is a separate mapping — not a flag on the user. This meant role changes didn't cascade unexpectedly, and audit trails could answer "who had what role when" without guessing. For a system that holds records belonging to minors, that precision is a legal requirement, not a preference.

Outcome

Edulib's identity backbone runs through the fabric we built. A student enrolling on Monday has a classroom account on Monday. A teacher moving to a new school is on the right mailing list the same day. When the platform updates and a backend goes dark for twenty minutes during a maintenance window, no event is lost and no operator needs to intervene — the fabric absorbs the gap and catches up. That is what national-scale integration looks like when it works.

“Student identity is not a feature. It's the contract between the state and every family whose child is in school.”

Your system has a story. We make sure the next chapter ships

Start the conversation