You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Zur Kommunikation studentischer Matrikelnummern an Stellen der öffentlichen Verwaltung oder andere Systeme, die dieses Verwaltungsdatum benötigen.

Do not consume uncooked!

Dem ACOnet-Team ist zur Zeit keine Nutzung der unten vorgeschlagenen Konvension bekannt. Auch wurde die Länge von Matrikelnummern mittlerweile vom zuständigen Ministerium verändert.
Untenstehendes ist also als historisches Dokument zu betrachten, nicht als gültiger Implementierungsvorschlag.

Geltungs- und Nutzungsbereich

Anwendungen, die studienrelevante Daten verwalten, brauchen u.U. zur eindeutigen Identifikation von Studierenden neben Vor- und Zuname (oder/und Geburtsdatum) auch die österreichweit eindeutige Matrikelnummer. Sofern keine technische Verbindung zu Systemen der öffentlichen Verwaltung besteht, sollte jedenfalls auf die Nutzung der Matrikelnummer als name identifier verzichtet werden – ebenso wie z.B. Sozialversicherungsnummern nur innerhalb des für sie bestimmten Bereichs eingesetzt werden sollten.

Matrikelnummern sind keine guten Identifier für Personen (auch etwa als Teil von UserIDs oder Email-Adressen) oder anderen Gebrauch außerhalb der Lehrverwaltung im engeren Sinn, da es durch (Korrektur von) Falsch- bzw. Neuvergaben immer wieder zu Änderungen von Matrikelnummern kommt, auch wenn diese eigentlich lebenslang unverändert und landesweit eindeutig sein sollten. Änderungen von Identifiern sollten freilich immer möglichst vermieden, bei Matrikelnummern ist dies aber besonders problematisch, da diese – im Gegensatz zu anderen lokal vergebenen Identifiern – nicht unter eigener Kontrolle stehen.

Solche Änderung an Verwaltungsdaten sollten nach Möglichkeit auf Systeme der Lehrverwaltung beschränkt bleiben. Benutzt man die Matrikelnummer jedoch auch als Basis von UserIDs oder Email-Adressen, vervielfältigt man die Auswirkungen solcher Änderungen in alle IT-Systeme, unter teils hohem Aufwand für Datenmigration und BenutzerInnen-Support ("Ihre UserID, Email-Adresse, Homepage, eduroam-Identifier, etc. haben sich geändert, ..."). Im Kontext von Identity Federation wären dann auch Systeme außerhalb der eigenen Institution von solchen Änderungen betroffen, wenn etwa das eduPersonPrincipalName-Attribut aus der Matrikelnummer gebildet wird und diese sich ändert: Damit änderte sich auch der ggfs davon abgeleitete eduPersonPrincipalName, und Betroffene verlören damit u.U. Zugriff auf ihre Daten bei diversen föderierten Services, die sich auf das eduPersonPrincipalName-Attribut zur Wiedererkennung ihrer NutzerInnen verlassen. Im Anlassfall alle davon betroffenen Services zu ermitteln und zu verständigen und um deren Kooperation bei der Korrektur/dem Nachtragen solcher Änderungen zu ersuchen, erscheint wenig verlockend.

Implementierung eduID.at

Zur Zeit ist von keinem eduID.at Service Provider eine Nutzung dieses Datums bzw. des unten spezifizierten Attributs bekannt.


SCHAC personalUniqueCode

Im international eingesetzten SCHAC-Schema wurde das Attribut schacPersonalUniqueCode definiert, das u.a. für die Kennzeichnung der studentID verwendet wird. Die Werte dieses Attributs sind URNs, mit standardisierten Prefixen, siehe dazu die SCHAC-Spezifikation. Sofern also die studentische Matrikelnummer als SAML-Attribut übertragen werden soll, empfielt ACOnet die Nutzung des Attributs schacPersonalUniqueCode. Werte haben dabei die Form:

Beispiel Attributwert, für Matrikelnummer 12345

urn:schac:personalUniqueCode:int:studentID:AT:0012345

Der numerische Wert der Matrikelnummer ist dabei ggfs. mit führenden Nullen auf acht Zeichen aufzufüllen!

Shibboleth IDP

Nachdem dieses Attribut nicht in genau dieser Form bereits irgendwo gespeichert sein wird, folgt ein Beispiel, wie dynamisch aus dem Attribut uid (das aus dem DataConnector mit der id="myLDAP" kommt) die Matrikelnummer extrahiert und in die benötigte Form gebracht werden kann. In diesem fiktiven Beispiel enthält uid eine lokale UserID, die für Studierende die Form x<MATRIKELNR> hat. Hat die UserID nicht die erwartete Form, bleibt das Attribut leer (und wird vom IDP später entfernt):

<AttributeDefinition id="matrikel" xsi:type="Mapped" sourceAttributeID="uid">
    <Dependency ref="myLDAP" />
    <ValueMap>
        <ReturnValue>urn:schac:personalUniqueCode:int:studentID:AT:$1</ReturnValue>
        <SourceValue>^x([0-9]{8,})$</SourceValue>
    </ValueMap>
    <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false" />
</AttributeDefinition>

Statt uid kann hier also jedes existierende Attribut eingesetzt werden, das bereits eine Form der Matrikelnummer enthält, etwa Emailadresse (mail) oder eduPersonPrincipalName.

Eine passende Regel, dieses Attribut (bzw. nur syntaktisch korrekte Werte davon) nur an aufgezählte Service Provider weiterzugeben, und nur, wenn das Attribut eduPersonAffiliation den Wert student hat (also nur für Studierende), könnte beim Shibboleth IDP so aussehen:

<AttributeFilterPolicy id="Matrikelnummer">
    <PolicyRequirementRule xsi:type="AND">
        <Rule xsi:type="OR">
            <Rule xsi:type="Requester" value="https://test-sp.aco.net/shibboleth" />
            <Rule xsi:type="Requester" value="https://sp.example.org/studentsoftware" />
        </Rule>
        <Rule xsi:type="Value" attributeID="eduPersonScopedAffiliation" value="student" />
    </PolicyRequirementRule>
    <AttributeRule attributeID="matrikel">
        <PermitValueRule xsi:type="ValueRegex" regex="^urn:schac:personalUniqueCode:int:studentID:AT:[0-9]{8,}$" />
    </AttributeRule>
</AttributeFilterPolicy>
  • No labels