Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:aai:eduid_ws_nov_2019 [2019/12/05 11:41] – Wolfgang Pempe | de:aai:eduid_ws_nov_2019 [2019/12/05 11:48] – Wolfgang Pempe | ||
---|---|---|---|
Zeile 5: | Zeile 5: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
- | {{INLINETOC 2}} | ||
====Ausführliche Agenda und Notizen ===== | ====Ausführliche Agenda und Notizen ===== | ||
(die neuen Use Cases sind auf [[https:// | (die neuen Use Cases sind auf [[https:// | ||
Zeile 30: | Zeile 29: | ||
* Zusammenfassung und nächste Schritte | * Zusammenfassung und nächste Schritte | ||
- | ==== Fragen an SWITCH ==== | + | **[[de:aai:eduid:switch|Fragen an SWITCH]]** |
- | | + | |
- | | + | |
- | * Von rund 450.000 Konten sind ca. 150.000 auf edu-ID umgestellt. | + | |
- | * Hinweise der IT werden nicht immer befolgt. | + | |
- | * Benutzer muß neues Passwort für edu-ID anlegen. | + | |
- | * SPs müssen technisch nichts anpassen (außer Oberfläche), | + | |
- | * Support muss entsprechend geschult werden, um auf Fragen | + | |
- | * Passwortmanagement | + | |
- | * Aktuelle (!) NIST-Empfehlungen werden angewendet. Beschreibung: | + | |
- | * MFA im eduID Bereich umgesetzt durch TOTP (Google Auth), SMS-basiert, | + | |
- | * Passwort-Reset über automatischen Service, Versand eines Links per Mail, mit dem man neues PW setzen kann. | + | |
- | * Hinterlegung von mehreren Mail-Adressen, | + | |
- | * Authentisierung sowohl über edu-ID Credentials *als auch* Einrichtungs-Credentials möglich? | + | |
- | * Grundsätzlich möglich, aber es wird abgeraten, da dadurch Nutzer sich entscheiden muss und Workflow soll nicht mit Entscheidungen des Benutzers belastet werden. In Fällen, in denen die Anmeldung mit beiden Credentials sinnvoll ist, ist das auch möglich. | + | |
- | * Nutzer sollen immer wissen, was sie eingeben müssen (lokal / eduID). | + | |
- | * Lokales Konto wird weiterhin bestehen bleiben, zB um auf lokale Ressourcen zuzugreifen; | + | |
- | * Alle über SAML erschlossenen Ressourcen gehen über eduID; bei eduID Login Möglichkeit des Co-Branding | + | |
- | * Viele Universitäten möchten lokale Konten loswerden und alle Dienste auf eduID umstellen (?) | + | |
- | * eduroam: Wenn Login bei edu-ID mit Affiliation erfolgt und die Hochschule eduroam hat, dann wird gleich ein Zertifikat und die eduroam-Profile zum Download zur Verfügung gestellt. | + | |
- | * In PC Pools lokales Konto der Hochschule, nicht über eduID. | + | |
- | * Lokales Kerberos-Ticket kann auch zur Authentisierung an eduID benutzt werden. | + | |
- | * Welche Kernattribute? | + | |
- | * Attributspezifikation der AAI wird weiter verwendet, nichts Neues dazu erfunden außer Qualitätsattribute speziell für die eduID ((un-)verifizierte eduID): https:// | + | |
- | * Attribute werden mit Nutzerzustimmung aus den Einrichtungen übernommen (Name, Mail etc.). | + | |
- | * AttributeQuery nachts, um Affiliations aktuell zu halten. Welche Werte in welchem Zeitraum vorhanden waren, wird protokolliert. | + | |
- | * Bei SwitchAAI haben sie als Affiliation nur " | + | |
- | * Neues Attributmodell (" | + | |
- | * Required Attribute für Erstellung einer eduID: | + | |
- | * EMail-Adresse (als Username) | + | |
- | * Name | + | |
- | * Vorname | + | |
- | * Selbstgewähltes PW | + | |
- | * Eingabe von Captcha (gegen Bots) | + | |
- | * Für MFA Handynummer | + | |
- | * Geburtsdatum für bestimmte Dienste | + | |
- | * Verifizierung und Qualität der Kernattribute? | + | |
- | * kostenpflichtige Verfahren, zw. EUR 10 und 25 (nicht implementiert) | + | |
- | * Üblicherweise strenge Prozesse beim Onboarding (Immatrikulation) | + | |
- | * Wohnortnachweis über Post an Postanschrift (implementiert) | + | |
- | * Verfahren zur Dublettenerkennung? | + | |
- | * Cookie im Browser zur Wiedererkennung, | + | |
- | * Nutzungsbedingungen schließen mehrere Konten aus. | + | |
- | * Viele eineindeutige Attribute (E-Mail-Adresse, | + | |
- | * Erkennung über Verlinkung mit einrichtungslokalem Konto | + | |
- | * Hinweis an den Benutzer, dass wohl Konto schon besteht und Angebot, Konten zu verschmelzen; | + | |
- | * Automatisiertes Verfahren bei SWITCH, es leiden eher die SP-Betreiber | + | |
- | * Dubletten zu bereinigen ist viel Aufwand, daher möglichst an der Quelle schon die Dublette verhindern | + | |
- | * Letztlich wird Erstellung von Zweitaccounts nicht verhindert, aber zumindest in Großteil der Fälle so schnell erkannt, dass die neue ID keinen Schaden anrichtet | + | |
- | * Aggregierung von außeruniversitären Daten/ | + | |
- | * ORCID: gleichzeitiges Login zur Attributübertragung | + | |
- | * Diskutiert auch mit SwissID (bietet Dienst wie Verimi in Deutschland) | + | |
- | * Föderation für Primar- und Sekundarstufe der Schulen, angedacht ist überföderative Zusammenarbeit; | + | |
- | * Validierung ORCID? | + | |
- | * Verfahren von ORCID bereitgestellt (basiert auf OAuth2) | + | |
- | * Details zur (SCIM) Push-API? | + | |
- | * Link zur Doku: https:// | + | |
- | * Zwei Wege zur Erstellung einer Affiliation | + | |
- | * Nutzerzentrisch (nächtliche Attribute Query) -> User loggt sich ein (eduid.ch), wirft Prozess " | + | |
- | * Heimatorganisation macht API-Push auf REST Schnittstelle (CRUD) und erstellt Affiliation für Nutzer; schnellerer Prozess, empfohlen (hab ich das richtig verstanden? | + | |
- | * Alle 4 Organisationen haben das API implementiert (ist aber nicht zwingend) | + | |
- | * OrgAdmin Interface, auf dem sich Heimatorganisationsadmin anmelden kann und alle Affiliations einsehen kann | + | |
- | * Heimateinrichtung kann regelmäßig Liste abholen und in eigenem Datensatz hinterlegen (Mapping über gemeinsamen Identifikator für Affiliation, | + | |
- | * Ab dann keine Möglichkeit mehr für Nutzer, selbst eine Affiliation anzulegen, sondern wird auf Seite der Heimatorganisation weitergeleitet | + | |
- | * Unterscheidung bei SWITCH zwischen bestehenden Nutzern, die bereits lokales Konto haben, und neuen Konten; jeweils verschiedene Prozesse | + | |
- | * Neue Nutzer: Legen sich eine EduID an und loggen sich danach auf einer speziellen URL der Heimateinrichtung ein, wo dann die EduID abgespeichert wird. | + | |
- | * Bestehende Nutzer: "Macht Euch eine eduID, verlinkt sie und gut" | + | |
- | * Granularität von Affiliations? | + | |
- | * zwei Affiliations in einer Einrichtung, | + | |
- | * Anzeige von allen Rollen, die ein Nutzer hat und Abfrage "In welcher Rolle möchtest Du Dich anmelden?" | + | |
- | * Übermittlung beider Rollen? | + | |
- | * Ist möglich | + | |
- | * Klassisches Modell: Nur eine Rolle übermittelt, | + | |
- | * Extended Model: Mehrere Mail-Adressen und Affiliations werden an Dienst übermittelt und dort muss entchieden werden, was damit angefangen wird | + | |
- | * Bsp eduroam: Alle affiliations werden übermittelt, | + | |
- | * Welches Modell verwendet wird, wird in der ResourceRegistry festgelegt. Das ist bislang nur innerhalb der Switch-AAI möglich, da proprietär. --> DFN-AAI: zukünftig Entity Category(? | + | |
- | * Bilaterales Abkommen mit der DFN-AAI ist sehr willkommen ;) | + | |
- | * Einsatz der edu-ID im Ausland | + | |
- | * Nicht so sehr, Deutschland einziges Land neben der Schweiz, das sich in der Tiefe mit dem Thema beschäftigt | + | |
- | * Holland und Schweden haben auch Ansätze | + | |
- | * Nutzung eduroam mit Swiss eduID | + | |
- | * Lösung, bei der anhand der übertragenen Affiliations entschieden wird, ob Berechtigung existiert, dann wird Zertifikat plus Profil erstellt (Rückgriff und Weiterentwicklung von GÉANT-Software) | + | |
- | * Integration von Swiss eduID in MyAcademicId? | + | |
- | * eduGAIN ja, European Student Card nein, MyAcademicID nein | + | |
- | * "Die andere Studierendenkarte" | + | |
- | * Integration emrex / European Student Id in Swiss eduID | + | |
- | * European Student ID für Schweiz nicht anwendbar | + | |
- | * emrex noch keinen Kontakt | + | |
- | * warum Entscheidung für das radikale Modell (zentraler IDP emuliert lokale) | + | |
- | * Leben wäre einfacher gewesen mit einem hub-and-spoke Verfahren | + | |
- | * Schweiz macht beides, radikale Methode wird empfohlen | + | |
- | * Zukunftsträchtiger | + | |
- | * Auch im Hinblick auf neue Protokolle wie OIDC | + | |
- | | + | |
- | | + | |
- | * Was muss am SP angepasst werden? | ||
- | * Nichts | ||
- | * Naja fast... (--> Extended Attribute Model) | ||
- | * EntityID, Endpoints und Filterregeln des Heimatorganisations-IdP wird von eduID IdP übernommen. | ||
- | * Lokale Attribute sollen in Resource Registry dokumentiert werden und können dann direkt auf zentralen IdP übernommen werden. | ||
- | * In Fällen wo umfangreiche Anpassungen vorgenommen wurden wird empfohlen, weiter das interne Konto zu verwenden. | ||
- | |||
- | * Deprovisionierung? | ||
- | * Affiliations werden gelöscht durch Nachpflege durch die Heimatorganisationen | ||
- | * Identitäten bleiben bestehen | ||
- | * Anschreiben der Kontoinhaber, | ||
- | * Identitätsmerkmale (EMail, Handynummer) bleiben bestehen | ||
- | * Sonstige Kerndaten werden gelöscht | ||
- | * Nach Inaktivität von einem Jahr wird gesperrt (bedingt durch Nationallizenzen), | ||
- | * Löschfrist nicht zu kurz wählen (mind. 10 Jahre) | ||
- | |||
- | * Supportaufwand? | ||
- | * Derzeit 150.000 Konten rein eduID und eine einzelne Person ist mit dem Support nicht voll ausgelastet. | ||
- | |||
- | * Sonstiges | ||
- | * Zweckbindung: | ||
- | * Nochmals der Wunsch nach bilateralen Zusammenarbeiten |