Identitatea elevilor la scară națională — coloana vertebrală a Edulib
Pentru programul Edulib al Ministerului Educației din România am construit țesătura de integrare care sincronizează datele elevilor din sistemul național de informații școlare într-un strat de identitate federată — și mai departe în instrumentele de clasă pe care elevii le folosesc efectiv.
Scara problemei
Sute de școli. Sute de mii de conturi de elevi. Profesori, directori, personal administrativ — fiecare cu un rol care stabilește ce poate vedea și face în platformă. Fiecare cont are un ciclu de viață: e creat când elevul intră în sistem, mutat între grupuri pe măsură ce avansează prin ani și clase, legat de note și prezențe, și retras la final. Nimic din asta nu e static. Într-o zi obișnuită sistemul procesează mii de schimbări de identitate.
Identitatea în centru
WSO2 Identity Server a gestionat modelarea utilizatorilor, grupurilor și organizațiilor pe partea Edulib. Azure Active Directory a provizionat conturile efective cu care elevii și profesorii s-au autentificat. Cele două trebuiau să rămână consistente pe întreg ciclul de viață — creezi un utilizator în SIIR, și în câteva secunde atât WSO2 IS, cât și Azure AD îl reflectă. Asignezi utilizatorul unui grup, și permisiunile lui se actualizează în ambele. Retragi utilizatorul, și ambele știu. O inconsistență între cele două înseamnă un utilizator care se poate autentifica, dar nu poate face nimic — sau invers. Genul de problemă pe care un profesor la clasă nu are timp s-o depaneze.
Țesătura de integrare
Opt interfețe de integrare consumau din cozi ActiveMQ, fiecare gestionând o parte din ciclu — creare utilizator, asignare grup, gestionare note, ștergere utilizatori, sincronizare organizații, mapare roluri. Transportul bazat pe cozi a însemnat că o indisponibilitate temporară în Azure AD sau WSO2 IS nu pierdea evenimente; se acumulau și drenau când backend-ul revenea. Fiecare coadă avea propriul dead-letter channel pentru ce nu putea fi procesat nici după retry. Când operatorul se uita la DLQ, fiecare mesaj era corelat — puteau spune exact ce înregistrare de elev a eșuat și de ce.
Suprafața publică — apiport.edu.ro
O parte din datele Edulib trebuia să fie accesibilă pentru terți — alte ministere, vendori de software educațional, agenții statistice. Pentru asta am expus un REST API public la apiport.edu.ro, construit cu convențiile WSO2 API Manager: contracte versionate, control al accesului pe OAuth2, throttling per consumer. Sistemele externe n-au primit acces direct la magazinul de identitate; au primit o suprafață API guvernată, contract-first, pe care Ministerul o putea audita cap-coadă.
Guvernanță și audit
Organizațiile, rolurile și permisiunile au fost modelate separat cu intenție. O școală e o organizație. Un profesor e un utilizator. Rolul care face dintr-un utilizator director la o școală și profesor obișnuit la alta e o mapare separată — nu un flag pe utilizator. Asta a însemnat că schimbările de rol nu cascadau neașteptat, iar audit trail-urile puteau răspunde la „cine a avut ce rol și când" fără să ghicească. Pentru un sistem care deține înregistrări ale minorilor, precizia asta e o cerință legală, nu o preferință.
Rezultat
Coloana de identitate a Edulib rulează prin țesătura pe care am construit-o. Un elev înscris luni are cont de clasă luni. Un profesor care se mută la o școală nouă e pe lista corectă de distribuție în aceeași zi. Când platforma se actualizează și un backend cade pentru douăzeci de minute într-o fereastră de mentenanță, nu se pierde niciun eveniment și niciun operator nu trebuie să intervină — țesătura absoarbe pauza și recuperează. Asta arată integrarea la scară națională când funcționează.
„Identitatea elevului nu e o funcționalitate. E contractul dintre stat și fiecare familie al cărei copil e în școală."