edu-ID Meeting 27.11.2020

(zurück zur Übersicht)
Videokonferenz, 9:00-13:00

Inhaltsverzeichnis

Agenda

  • Hausaufgaben und offene Aktionen
  • Infoshare
  • Fragen an SWITCH
  • Breakout Sessions
    • Konsolidierung Attributsatz
    • Levels of Assurance
  • Berichte aus den Sessions und weiteres Vorgehen
  • Sonstiges

Pad für Notizen: https://pad.gwdg.de/lCrugUIVQeqa1HK347R_fQ?both

Hausaufgaben und offene Aktionen

VC am 23.6.2020

  • Dokumentenablage, Projektmanagement, Nextcloud → Wolfgang

Infoshare

  • Rückschau - was bisher geschah - wo stehen wir?
  • Update MyAcademicID und ESI (WP)
    • Eigener Identifier innerhalb der Erasmus-Plattform ist der European Student Identifier (ESI)
    • ESI muss zukünftig vom IdP der jew. Hochschule übertragen werden
    • Derzeit noch keine Verknüpfung zum OZG geplant
  • Update zu eIDAS, OZG, SHIELD (DH)

Fragen an SWITCH

  • Wie ist (unser) UC 2.3 umgesetzt?
    • Nutzung von eduroam für weitere Dienste
    • Pilot der SWITCH hat die Pilotphase leider nicht verlassen, zu wenig Organisationen, die auf die neue Lösung hätten wechseln wollen, daher zu wenig Interesse
    • edu-ID weiß, ob Person berechtigt ist, eduroam zu nutzen, eigener RADIUS-Server, der Anfragen von eduroam beantwortet
    • Entlastung der Universitäten durch Übernahme des Betriebs und der Technik durch die Föderation
      • Wesentliche bessere Sicherheit durch zentrales Zertifikatsmanagement
    • Einrichtungseigene WLAN Lösung wird zum Teil parallel gefahren
      • Entweder: Schalte eduroam nur ein, wenn du nicht zuhause (bei uns) bist
      • Oder: Du kannst eduroam auch in unserem Netz nutzen
    • Verbreitung von eduroam in Deutschland sehr groß, kein wirklicher Bedarf, nicht-angeschlossene Einrichtungen (gibt es die? Rückfrage an die Föderation, wird dort intern geklärt) mit einer Föderationslösung zu bedienen
    • → UC 2.3 niedrig priorisiert
  • Wie ist der Stand von SLSP (Swiss Library Service Platform) und Anbindung an edu-ID?
    • Swisscovery geht live am 7.12.
    • Setzt exklusiv auf edu-ID zur Authentifizierung
    • Bei Registrierung werden die Affiliations der Person übernommen
    • Bei Personen, die noch keine edu-ID haben, wird bei Anmeldung eine neue edu-ID angelegt
    • Durch Betrieb der SLSP wird ein großer Zuwachs der edu-IDs erwartet
    • Einerseits Schaffung neuer IDs, andererseits viele Verknüpfung bestehender IDs mit den jeweiligen Affiliations
    • 300k Identitäten, etwa die Hälfte hat Affiliation, etwa 400k Personen in der akademischen Welt
    • Rückfrage: Arbeitet die Plattform mit Affiliaton Chooser?
      • SLSP arbeitet mit extended Datenmodell, bekommt alle Affiliations einer edu-ID mit, Plattform muss selbstständig entscheiden, wie sie mit dieser Tatsache umgeht
    • Bibliotheken und Hochschulen sind mitunter zwei verschiedene Welten
      • Verteilen von Informationen zu SLSP über die Bibliotheken, geht manchmal an den Informatikdiensten vorbei
      • Expliziter Hinweis von Seiten SWITCHaai, dass es sich um dieselbe Welt handelt
    • Wenn ich die Hochschule verlasse, bleibt die edu-ID bestehen und die Affliations werden eingekürzt, d.h. die Person kann auf weniger Lizenzen zugreifen - sonst ändert sich nichts
    • Planung in Deutschland zu analogem Dienst?
      • Eher nicht… Höchstens bei den Fachinformationsdiensten
    • Föderalismus gibt es auch in der Schweiz: „Kantönlegeist“
    • Föderierte kantonübergreifende Dienste:
      • SWITCH
      • Edulog
      • SLSP
      • Manchmal gibt es Dienste, die kantonübergreifend funktionieren :)
    • Benutzer wird informiert, wenn Affilition verloren geht
      • Information per Mail (derzeit von SWITCH aus): Ihr hattet eine Verbindung zu einer Einrichtung, diese Verbindung besteht jetzt nicht mehr
      • Außerdem auch Ansicht, welche Affiliations jetzt gerade zur edu-ID gehören
  • Umgang mit „local attributes“ / Entitlements für spezielle Dienste, z.B. im Proxy-Szenario. Wie technisch / organisatorisch gelöst?
    • Proxy zwischen Services und manchen IdPs, weil die Dienste zT technische Unzulänglichkeiten haben (kein Umgang mit mehreren IDs, kein sauberes SAML2, …)
    • Implementierung eines Affiliation Choosers z.B. für Adobe, Auswahlmöglichkeit für Nutzer „Mit welcher E-Mail-Adresse möchtest Du bei Adobe auftreten?“
    • Muss leider immer wieder gemacht werden, weil die SAML2-Anbindung der Services nicht sauber umgesetzt werden kann
    • wenn lokales Entitlement vorhanden, dann Teil der Affiliation
    • wenn Info nicht im IdM der HE, dann externe Info → Sharded Property Database → Entitlement über edu-ID (Bsp. Nationallizenzen), skaliert nur bedingt (daher nur in Ausnahmesituationen)
    • Gruppenmanagement sollte eigentlich immer durch die Ressourcen-Anbieter erfolgen, z.B. FID, Research Communities
    • Interoperabilität edu-ID-Systeme → internationale Forschungsinfrastrukturen (welche edu-ID 'gewinnt'?)
    • SLSP akzeptiert aktuell nur SWITCH edu-ID
  • Levels of Assurance bei SWITCH edu-ID
    • https://www.switch.ch/edu-id/services/attributes/quality-levels/
    • Definition spezieller Attribute, die die Informationen transportieren
    • Diskussion: Ein LoA für das gesamte Attributset vs. Beschreibung der Attribute
      • Attribute kommen von verschiedenen Stellen, deshalb werden die LoAs auf Ebene der Attribute beschrieben
    • Ingesamt wenig Nutzung
    • Bei der Erstellung einer Affiliation werden alle Attribute validiert
    • Entsprechende gleichartige Attribute in persönlichem Kontext vorhanden? → Attribute in pers Kontext überschrieben mit Affiliation Attributes und gleichzeitig erhöhen der LoA
    • Benutzer ändert Attribute in pers Kontext → LoA wird wieder verringert
    • Jeweils Zeitstempel der letzten Validierung
    • Bei neuer Verlinkung mit einem Organisationskonto wird das Validierungsdatum zurückgesetzt
      • Es gibt die Möglichkeit einer Neuverlinkung mit einem bestehenden Konto, um die Daten neu aus dem Affiliationkontext in den persönlichen Kontext zu übernehmen
    • Für Nationallizenzen muss das Konto aktiv sein
      • Was heißt das? Aktiv im letzten halben Jahr
      • Speicherung von Datum des letzten Zugriffs des Kontos, Konto kann also ablaufen
    • Im Datenmodell Abbildung durch „Attribute an Attributen“

Gruppenarbeit

Erfolgt in separaten Meetings während der nächsten Wochen

Weiteres Vorgehen

  • Zusammenfassung der Anforderungen um damit „Hausieren zu gehen“
  • Und dann auch tatsächlich „hausieren gehen“ und Mittel und Personal einwerben
  • Wohlwollen der verschiedenen möglichen Partner ist da
  • Weitere Suche möglicher Partnerschaften ist notwendig
  • Alles beisammen, was für eine Antragsskizze notwendig ist
  • Parallelbetrieb
    • Technische Details weiter besprechen
    • Mindestens eine, besser mehrere Personen, die sich hauptamtlich u.a. mit der Organisation beschäftigen
  • Anfangen mit erst mal einem Use Case und dann nach und nach die anderen Use Cases einbringen
  • Weitere für das edu-ID Konzept relevante Punkte:
  • Treffen zukünftig nur zu jeweils einem Schwerpunktthema, dafür dann kürzer
  • Hausaufgaben:
    • Infos zu NFDI zusammenstellen und dokumentieren (Wolfgang)

Nächste Termine

  • Zuletzt geändert: vor 4 Jahren