Institutionelle Umbenennung und eduID.at

"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 einer Änderung der entityID bestanden, muß temporär ein zweiter IDP mit der neuen entityID registiert werden, was zwar Gelegenheit gibt, Services einzeln auf den neuen IDP umstellen zu lassen, was aber Monate bis Jahre (je nach Anzahl und Kooperationswilligkeit der Servicebetreiber:innen) dauern kann.
In dieser gesamten Zeit werden von den meisten Services beide IDPs zur Anmeldung angeboten, auch wenn evtl. jeweils nur einer davon (und nicht immer derselbe) funktionieren wird. Welchen der zwei IDPs man pro Service auswählen muß, ist für die Nutzer:innen nicht erkennbar/vorhersehbar und bietet damit reichlich Potentiel für Verwirrung und erhöhte Arbeitslast (durch Zugriffsprobleme auf Services und Daten) beim eigenen IT-Support.

"Scoped attributes": eduPersonScopedAffiliation
z.B. student@hochschule-burgenland.at
z.B. student@fh-burgenland.at

Pro Institution sind mehrere "Scopes" erlaubt – nur mit diesen "Scopes" qualifiziert dürfen dann Attribute ausgestellt werden, die als "scoped" definiert sind. "Einschleichen" der neuen Scope und "Ausschleichen" der alten Scope bei eduPersonScopedAffiliation ist 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
z.B. userid@univie.ac.at

SAML Subject-ID
z.B. opaque-userid@boku.ac.at

SAML Pairwise-ID
z.B. service-specific-userid@tuwien.ac.at

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 potentiell wichtigen) föderierten Services verloren, die sich auf diese Attributwerte zur Wiedererkennung der Person verlassen.

Subject-ID und Pairwise-ID sind relativ neu, auf diese werden sich bisher (Stand 2025 CE) evtl. nur wenige Services verlassen – und diese sollte man an entsprechenden SAML-Metadaten verlässlich erkennen (EntityAttribute urn:oasis:names:tc:SAML:profiles:subject-id:req wird angefordert).

Die Nutzung von eduPersonPrincipalName ist etwas weniger klar erkennbar: Es ist Teil des REFEDS Research & Scholarship "attribute bundle" und wird damit wohl von allen Services dieser Kategorie verwendet. Weitere Services (ohne die REFEDS R&S-Kategorie) müssten dieses Attribut (wie üblich) individuell in den SAML-Metadaten über RequestedAttribute-Elemente anfordern.

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 oben empfohlen wird.

In der eduPerson-Spezifikation ist zwar vorgesehen, daß man den vorherigen Wert eines geänderten eduPersonPrincipalName-Attributs als (mehrwertiges!) eduPersonPrincipalNamePrior-Attribut mitschickt, ob das aber von Services auch genutzt wird, um den Zugriff auf der Service aufgrund des eduPersonPrincipalNamePrior-Attributes weiterhin zu gewähren (oder zumindest einen entsprechenden administrativen Prozess beim Service auslöst) ist unbekannt und jedenfalls für die meisten Services anzuzweifeln.
(Für die vergleichsweise neueren Attribute SAML Subject-ID und SAML Pairwise-ID gibt es keinen solchen Mechanismus.)

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
z.B. hochschule-burgenland.at

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.
Das sind vermutlich nur wenige.

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 unterscheidet.)

Der Wer der "Scope" (siehe oben) wird auch als schacHomeOrganization-Attribut weitergegeben, dieses Attribut darf aber (im Gegensatz zu den "Scopes") 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.
Auch Zugriffe auf die RDB können davon betroffen sein, wenn (wie dort beschrieben) Ausnahmeregeln für IP-Adress-unabhängige Zugriffe mit der Fa. Manz getroffen wurden.

Persönliche E-Mail-Adressen

Änderung wird immer notwendig sein (aus Gründen, die mit Identity Federation nichts zu tun haben).
Für Nutzer:innen sehr prominent "sichtbar".
("Ihre E-Mail-Adresse – und damit bei vielen Services auch: Ihre Benutzer:innenkennung – hat sich geändert!")

Obwohl E-Mail-Adressen per se mit SAML WebSSO/eduID.at/eduGAIN nichts zu tun haben (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.
(Massenweise/Batch-Umstellung von allen, gleichermaßen betroffenen, Nutzer:innen wird dabei vermutlich leichter ablaufen, als wenigen/einzelnen Nutzer:innen, ggfs. über mehrere Services verstreut, wieder zum Zugriff auf deren Services/Ressourcen/Projekten/etc. zu verhelfen.)

^(*) 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 ist das Attribut für E-Mail-Adressen 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 (gilt also nicht für die entityID oder den Hostnamen) festgemacht wird, gilt daher eine der zwei folgenden Migrationsstrategien:

• Mit zusätzlicher Konfiguration/Komplexität im SAML IDP pro Service entscheiden, ob das Service schon auf Nutzung der neuen Domain/"Scope" umgestellt wurde und dann also jeweils nur den neuen Attributwert schicken (oder anderenfalls weiterhin jeweils nur den alten Wert).
• Alternativ erfolgt die Umstellung an einem Stichtag für alle Services – die davon natürlich im Vorhinein verständigt und um Kooperation ersucht werden sollten. (Es braucht dabei aber vermutlich einen Plan B, daß Services nicht wie gewünscht/zeitgerecht umstellen oder dazu auch garnicht willens sind!)