OneRoster (1.2 und erweiterte Gruppen)

OneRoster ist ein internationaler Standard für den Austausch von Schulverzeichnissen (herausgegeben von 1EdTech): Er beschreibt in einem gemeinsamen Format die Einrichtungen, die Schuljahre, die Kurse, die Klassen, die Einschreibungen und die Benutzer einer Schule. Er dient dazu, ein SIS, ein Schulportal oder ein LMS ohne erneute Erfassung und ohne proprietäres Format an ein anderes Werkzeug anzubinden.

Diese Seite richtet sich an die IT-Abteilung der Einrichtung. Sie beschreibt, was Omniscol in OneRoster bereitstellt und einliest, die erwartete Authentifizierung und den tatsächlichen Umfang jeder Austauschrichtung.

Unterstützte Versionen

Omniscol unterstützt OneRoster 1.2 Rostering — den Grundstock (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — sowie die Schicht OR-Groups (Advanced Groups Service), den additiven Gruppenstandard, der drei Entitäten (Group, GroupMembership, GroupAssociation) auf 1.2 aufsetzt.

Die Schicht OR-Groups ist ein Standard in der Veröffentlichungsphase. Sie ist streng additiv zu 1.2: Eine Group verweist lediglich auf die Entitäten Class / User / Org / AcademicSession von 1.2, schreibgeschützt. Die Version 1.3 von OneRoster ist angekündigt, um Class zu einer Spezialisierung von Group zu machen — eine Ausrichtung, mit der die Implementierung von Omniscol bereits konvergiert.

Omniscol als Produzent (Omniscol → Schulportal / LMS)

Als Produzent stellt Omniscol das Verzeichnis der Einrichtung schreibgeschützt über eine OneRoster-konforme REST-API bereit, damit ein Schulportal oder ein LMS es einliest.

  • Der Grundstock Rostering 1.2 wird unter /ims/oneroster/rostering/v1p2/… ausgeliefert (zum Beispiel /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, jeweils mit seinen verschachtelten Varianten).
  • Die Gruppenschicht wird unter /ims/oneroster/groups/v1p0/… ausgeliefert (/groups, /groupMemberships, /groupAssociations und ihren verschachtelten Varianten).
  • Der Umfang ist standardmäßig das laufende Schuljahr; ein Parameter erlaubt es, ein anderes Jahr zu adressieren oder alle Jahre abzudecken.

Die Daten spiegeln die konsolidierte Planung von Omniscol wider (aktive / veröffentlichte Stundenpläne). Der Produzent ist schreibgeschützt nach Wahl: Es wird kein Schreibzugriff (PUT / DELETE) bereitgestellt — ein entferntes System steuert nicht die Erstellung oder Löschung von Entitäten in Omniscol.

Authentifizierung des Produzenten

Die Zugangspunkte des Produzenten sind durch OAuth2 im Flow client_credentials geschützt (Maschine-zu-Maschine-Token, ohne Benutzer), ausgestellt vom OAuth2-Server von Omniscol. Sie sind nicht den Premium-Konten vorbehalten: Der Zugriff wird durch die OAuth2-Scopes gesteuert, nicht durch das Angebot. Jeder Scope ist spezifisch für einen Dienst, und der Zugriff auf demografische Daten ist innerhalb der 1.2 abgeschottet:

Zugangspunkte Akzeptierte Scopes
Rostering 1.2 (ohne Demografie) https://purl.imsglobal.org/spec/or/v1p2/scope/roster-core.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly
Rostering 1.2 /demographics https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster-demographics.readonly
OR-Groups (alle) https://purl.imsglobal.org/spec/or-groups/v1p0/scope/roster-group.readonly

Ein OR-Groups-Token gewährt keinen Zugriff auf den Grundstock Rostering, und umgekehrt. Es wird kein Schreib-Scope angekündigt. Die privilegierten Scopes werden von der Omniscol-Verwaltung zum Zeitpunkt der Registrierung des OAuth2-Clients zugeteilt; ein Client kann sie sich nicht selbst zuweisen. Die Verwaltung der OAuth2-Clients und der Token ist auf OAuth2 / OIDC (Anbieter) und Omniscol-API beschrieben.

Der Umfang der Schüler wird von der Gruppenschicht getragen

Strukturierende Wahl: Die Liste der Schüler einer Klasse oder einer Gruppe wird über OR-Groups (GroupMembership) bereitgestellt, nicht allein durch den Grundstock 1.2. Ein Konsument, der nur Rostering 1.2 liest, erhält den Katalog (Courses, Classes), die Einschreibungen Lehrkraft → Kurs und das Benutzerverzeichnis, aber nicht die Zugehörigkeit der Schüler. Um zu erfahren, wer in welcher Klasse oder welcher Gruppe ist, muss der Konsument die Schicht OR-Groups implementieren. Diese Wahl spiegelt das französische Modell wider: Ein Schüler ist in eine Klasse oder eine Gruppe eingeschrieben, nicht Fach für Fach.

Der Produzent stellt sich über REST bereit. Das Format OneRoster-CSV-Bundle (Zip-Archiv mit einer Datei je Sammlung) wird hingegen auf der Importseite unterstützt, für Anbieter, die ihr Verzeichnis per Datei statt per API liefern — siehe den Abschnitt zum Konsumenten weiter unten.

Omniscol als Konsument (SIS → Omniscol)

Import eines OneRoster-Verzeichnisses (SIS → Omniscol): Omniscol kann das Verzeichnis eines OneRoster-konformen SIS importieren — Einrichtung, Jahre, Kurse, Klassen, Gruppen, Benutzer und demografische Daten — über die REST-API des Anbieters oder ein CSV-Bundle, und es dann in die Einrichtung abgleichen. Diese Konsumentenkonfiguration ist Teil der Synchronisierung mit externen Systemen, die auf Premium-Konten verfügbar ist und projektbezogen mit dem Omniscol-Team abgestimmt wird.

Als Konsument importiert Omniscol das Verzeichnis eines OneRoster-konformen SIS und gleicht es in die Einrichtung ab. Diese Konsumentenkonfiguration ist Teil der Synchronisierung mit externen Systemen: Sie ist auf Premium-Konten verfügbar und wird projektbezogen mit dem Omniscol-Team abgestimmt (siehe Synchronisierung mit externen Systemen).

  • Transport — entweder die REST-API des Anbieters (die Basisadresse wird konfiguriert, die standardmäßige OneRoster-Paginierung wird befolgt), mit OAuth2-Authentifizierung im Flow client_credentials gegen den Server des Anbieters; oder ein CSV-Bundle (Zip-Archiv).
  • Profil — ein Konfigurationsprofil gibt den zu lesenden Umfang an: Grundstock 1.2 allein, Gruppenschicht oder französische Abbildung für die schulische Bildung. Ein rein 1.2-Anbieter, ohne Gruppendienst, wird sauber importiert.
  • Kontrollierte Anwendung — der Import folgt demselben Prinzip wie die anderen Konnektoren: Omniscol ruft die Daten ab und gleicht sie ab, und ein Administrator validiert die Anwendung auf die Einrichtung. Das entfernte System schreibt niemals direkt in Omniscol.
  • Idempotente Reimporte — die Zuordnungen der externen Identifikatoren bleiben erhalten, sodass ein Reimport keine Dubletten erzeugt, selbst wenn der Anbieter eine Beschriftung umbenennt.

Französisches Profil (schulische Bildung)

Das französische Profil für die schulische Bildung bildet die französischen Begriffe auf das OneRoster-Modell ab: Eine Klassenteilung (die Klasse im eigentlichen Sinne) wird zu einer Group des organisatorischen Haupttyps; eine Gruppe wird zu einer Group für die pädagogische Vermittlung; eine Gruppe von Gruppen zu einer übergreifenden Group; die Klassenteilungen und Gruppen-Ausrichtungen werden zu Gruppenassoziationen; die Zuweisung einer Lehrkraft zu einem Kurs wird zu einer Einschreibung der Lehrkraft. Identifikatoren wie die INE oder der Personalidentifikator werden in den userIds des Benutzers geführt.

Identifikatoren und Vertraulichkeit

Jede bereitgestellte Entität trägt einen stabilen Identifikator, die sourcedId.

  • Die strukturellen Identifikatoren (Einrichtung, Jahr, Kurs, Klasse, Gruppe) sind von einem Export zum nächsten stabil und unveränderlich: Ein Konsument kann sich darauf verlassen, um Daten über die Zeit hinweg zu korrelieren.
  • Der Identifikator des Benutzers ist anonymisiert: Omniscol überträgt niemals seinen eigenen namentlichen Identifikator nach außen. Das nach außen übertragene Token wird durch eine Einwegfunktion (HMAC) abgeleitet, die dem Konto eigen ist; die Einschreibungen und Zugehörigkeiten verwenden dieses Token wieder, ohne jemals den ursprünglichen Identifikator preiszugeben.

Status

  • Produzent — verfügbar und ohne entfernten Partner vorführbar (der Export genügt sich selbst). Rostering 1.2 und die Schicht OR-Groups werden schreibgeschützt bereitgestellt, mit OAuth2-Authentifizierung.
  • Konsument — die Importkonfiguration ist Teil der Premium-Synchronisierung. Die Inbetriebnahme einer Live-Synchronisierung mit einem SIS hängt vom Anbieter und gegebenenfalls von den ministeriellen Zeitplänen ab: Sie wird auf Anfrage abgestimmt, Konnektor für Konnektor. Es handelt sich nicht um eine sofortige, schlüsselfertige Synchronisierung.

Siehe auch