Entwurf
eduID.at
Mit Umbenennung der kanonischen institutionellen DNS-Domain sind mitunter weitreichende Änderungen verbunden, welche im schlimmsten Fall dauerhaft Zugang zu Services und Daten unterbinden. Ob bestehende Zugänge/Daten mit der neuen Domain wieder zugänglich gemacht werden können, liegt dabei – je nach dem, was man im Detail alles ändert – in der Regel beim Entgegenkommen (oder nicht) des Serviceanbieters.
(Manchmal kann das Nachziehen der Änderung beim Serviceanbieter durch berechtigte Personen in Selbstbedienung durchgeführt werden, etwa bei manchen Bibliotheksservices. In anderen Fällen muß man den Serviceanbieter um Änderung ersuchen. In hoffentlich wenigen Fällen verweigert sich der Serviceanbieter jeglichen administrativen Eingriffen und man muß dort die eigene Organisation praktisch von Null weg neu anlegen/konfigurieren und alle Nutzer:innen, Daten und Rechte neu einrichten.)
Im Folgenden werden links die wichtigsten Daten im Kontext von eduID.at /SAML WebSSO genannt, die sich bei Änderung der kanonischen DNS-Domain mit ändern können. Die Anzahl der möglichen Werte wird jeweils mit 1 ("single-valued"), 1+ ("multi-valued") oder * ("siehe jeweils Kommentar dazu in der rechten Spalte") angegeben, was mitentscheidend für die Durchführbarkeit gewisser Migrationsszenarien ist. Die Spalte "Umgang" umreißt, ob man dieses Datum ändern sollte oder besser nicht. Ein anschließender Kommentar in der gleichnamigen Spalte versucht Hintergründe und Konsequenzen zu nennen.
| Datum | Werte | Umgang | Kommentar |
|---|---|---|---|
| entityID – Global eindeutige Kennung einer SAML-Entity z.B. https://idp.fh-burgenland.at/idp/shibboleth | 1 | Möglichst beibehalten, ist für Nutzer:innen nicht sichtbar | "The most important attribute an entityID needs to have is persistence. The entityID is the public identifier for a deployment and is not only used throughout the deployment's own configuration, but more importantly will be used throughout all of the other deployments that it interoperates with. As such, changing it will have ripple effects throughout many systems you don't control, and will often take time to propagate (possibly a lot of time)." -- Entity Naming, Shibboleth Wiki Wird (durch fehlende Einsicht) auf Änderung bestanden, wird temporät ein zweiter IDP mit der neuen entityID registiert, was Gelegenheit gibt, Services einzeln auf den neuen IDP umstellen zu lassen (was Monate dauern kann). In dieser gesamten Zeit werden bei den meisten Services beide IDPs zur Anmeldung angeboten, was Verwirrung bei den Nutzer:innen auslösen kann. Zusätzlich wird die Anmeldung evtl. nur mit einem dieser zwei IDPs funktionieren, wenn das Service Autorisierung aufgrund der entityID oder Attribut-"Scope" vorgenommen hat. |
| Hostname / SSO-URL z.B. https://idp.hochschule-burgenland.at/idp/profile/SAML2/Redirect/SSO | 1* | Ändern | Manche der Endpunkte des IDP sind für Nutzer:innen gut sichtbar, wenn die Authentifizierung der Nutzer:innen direkt am IDP stattfindet → Ändern. (*) Ein IDP kann über mehrere Hostnamen (alt, neu) gleichzeitig angesprochen werden, in den Federation-Metadaten kann aber zu einem Zeitpunkt nur einer davon stehen. |
"Scoped attributes": eduPersonScopedAffiliation | 1+ | Neue Domain zusätzlich Eintragen, alte später Austragen. | Pro Institution sind mehrere "Scopes" erlaubt – nur mit diesen "Scopes" qualifiziert dürfen dann (diese) Attribute ausgestellt werden, die als "scoped" definiert sind. "Einschleichen" der neuen Scope und "Ausschleichen" der alten Scope bei eduPersonScopedAffiliation also möglich und sinnvoll! eduPersonScopedAffiliation ist "mehrwertig", könnte also meine Affiliation sowohl mit der alten wie auch der neuen Scope ausdrücken. Ein Service, daß mir aufgrund von eduPersonScopedAffiliation Zugriff gewährt, sollte mich dann solange "reinlassen", wie die alte "Scope" mitgeschickt wird bzw. bis der Serviceanbieter die Zugrffsregeln administrativ an die neue Scope angepaßt hat. Sichtbar ist dieses Attribut wohl nur im "Consent"-UI des SAML IDP, wo die zu übertragenden Attribute (und -werte) der Nutzer:in zur Kontrolle vorgelegt werden. |
"Scoped attributes": Diverse Identifier eduPersonPrincipalName SAML Subject-ID SAML Pairwise-ID
| 1 | Für Nutzer:innen bedingt sichtbar (legt ändern nahe). Mit Änderung der Domain (=Änderung der bislang beim Service hinterlegten Kennung) gehen potentiell persönliche Rechte bei (wenigen, aber für die Person wichtigen?) föderierten Services verloren, die sich auf diese Attribute zur Wiedererkennung der Person verlassen. Subject-ID und Pairwise-ID sind relativ neu, auf diese werden sich evtl nur wenige Services verlassen – und diese sollte man an entsprechenden SAML-Metadaten verlässlich erkennen! Die Nutzung von eduPersonPrincipalName ist deutlich weniger klar erkennbar: Es ist Teil des REFEDS Research & Scholarship "attribute bundle" undn wird damit i.d.R. nicht individuell in den SAML-Metadaten angefordert und manchmal vom Service evtl. nicht verwendet. | Diese Identifier sind alle "single-valued", es können also nicht "auf Verdacht" sowohl die bisherigen als auch die neuen Werte geschickt werden (wie das bei eduPersonScopedAffiliation der Fall ist, s.o.). In der eduPerson-Spezifikation ist zwar vorgesehen, daß man den vorherigen Wert eines geänderten Sichtbar sind dieses Attribute wohl nur im "Consent"-UI des SAML IDP, wo die zu übertragenden Attribute (und -werte) der Nutzer:in zur Kontrolle vorgelegt werden. |
schacHomeOrganization –Organisationskennung in Form der kanonischen DNS-Domain | 1 | Für Nutzer:innen bedingt sichtbar (legt ändern nahe). Als Kennung für die Institution/Organisation (nicht der Person) gehen bei Änderung potentiell Services verloren, die sich auf dieses Attribut zur Autorisierung verlassen. Eine potentielle Umstellung beim / durch den Serviceanbieter sollte vergleichsweise leicht durchführbar sein, da dieses Datum für die ganze Institution gilt und sich damit nicht pro Nutzer:in unterscheiden muß.) | Der Wer der "Scope" (siehe oben) wird auch als schacHomeOrganization-Attribut weitergegeben, dieses Attribut darf aber nur einen Wert haben! Für Unterzeichner der ECHE ist dieses Datum für Zugriff auf Erasmus+-Services evtl. bei der EU-Kommission hinterlegt, Änderung müssen dann über GÉANT/MyAcademicID gemeldet werden. |
Persönliche E-Mail-Adressen | 1* | Änderung steht außer Frage | Obwohl E-Mail-Adressen per se mit SAML WebSSO/eduID.at/eduGAIN nichts zu tun hat (diese sind nur Nutzdaten, wie etwa der Name einer Person), werden diese der Praxis oft als Username/UserID zur Anmeldung am SAML IDP benutzt. Oft wird auch der Wert der E-Mail-Adresse als Wert von "scoped"-Attributen (etwa eduPersonPrincipalName) wiederverwertet, womit letztere zwangsläufig mitgeändert werden. Persönlich zugänglich gemachte Ressourcen/Services (manchmal auch institutionell lizensierte Ressourcen, z.B. Zoom-Lizenzen) gehen verloren, wenn diese an der E-Mail-Adresse (oder dem eduPersonPrincipalName-Attribut) der Person festgemacht wurden. Ob eine Person mit veränderter Kennung wieder Zugriff auf bestenende Services erlangen kann, hängt dabei allein vom Entgegenkommen des Serviceanbieters ab. (*) Den relevanten Spezifikationen zufolge können beliebig viele Werte vorkommen/gesendet werden, nur können in der Praxis die wenigsten Services damit umgehen. Technisch/per se also "multi-valued", für weitreichende Interoperabilität aber eigentlich als "single-valued" zu betrachten. |
Allgemein: Für alle Services, von denen man weiß, daß der Zugriff an einem "single-valued" Attribut (nicht entityID, Hostname/SSO-URL) festgemacht wird – gilt daher eine der zwei folgenden Migrationsstrategien:
| |||
Überblick
Inhalte
Aufgabenbericht