Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:aai:eduid:ag1 [2019/12/05 16:11] – Wolfgang Pempede:aai:eduid:ag1 [2020/02/11 10:33] (aktuell) – Wolfgang Pempe
Zeile 1: Zeile 1:
 +~~NOTOC~~
 ====== Arbeitsgruppe WAYF ====== ====== Arbeitsgruppe WAYF ======
 +{{INLINETOC 2}}
 **Zweck: Vorbereitung des Workshops im Februar 2020**  **Zweck: Vorbereitung des Workshops im Februar 2020** 
  
Zeile 9: Zeile 11:
  
 **Teilnehmende: (bei Interesse bitte eintragen)**  **Teilnehmende: (bei Interesse bitte eintragen)** 
-  * David H.+  *<del> David H.</del>
   * Gerrit   * Gerrit
-  * ... +  * Thorsten 
 +  * Frank 
 +  * Martin H. 
 +  * Wolfgang 
 +  * Bernd 
 + 
 +===== Ergebnisse ===== 
 +==== Notizen ==== 
 +Thorsten: Weiß der User nach 5 Jahren Studium noch sein eudID PW?* 
 + 
 +Gerrit: keine redundante Discovery 
 + 
 +Wolfgang: nur eduID als IdP / DS, keine lokalen DSe 
 + 
 +Frank: lokale DS zusätzlich eduID IDP aufnehmen lassen 
 + 
 +Bernd: wohin für AuthN? Zum Uni-IdP? eduIDP nur als homeless IdP? --> am eduIDP als DS noch Heimat-IdP zulassen 
 + 
 +Siehe https://www.switch.ch/edu-id/services/attributes/extended-model/ für Scopes 
 + 
 +Bernd: Discovery mit Mail-Adresse, im 2. Schritt PW abfragen oder zum Campus IdP schicken 
 + 
 +Bernd: oder erst mal eine passive-Anfrage schicken? 
 + 
 +Bernd: Sie hatten am IdP früher eine Vorauswahl UB/Klinik/Uni, - Benutzer haben es nicht gecheckt 
 + 
 +? wie kann die PersistentID garantiert werden, wenn User eduIDP vs. lokaler IdP wählen können? 
 + 
 +Frank: eduID-IDP soll PersistentIDs einsammeln und alle releasen. 
 + 
 +NameID Management?? Der SP hat Hooks dafür, aber das wird wohl keiner implementiert haben. 
 + 
 +O365 nutzt persistentIDs für AttributeQueries? 
 + 
 +DataConnector für HeimatIdPs, der eduID-Rest-API anspricht. 
 + 
 +Jemand verliert seine Affiliation, wie kann er dann noch auf eduID umstellen? --> muss vorher passieren. 
 + 
 +Proxy: Authn am lokalen Idp? 
 + 
 +Sobald ein IdP eduID macht, muss er bei allen SPs aus deren EDS raus.  
 + 
 +Affiliation Chooser nach Login. 
 + 
 +Martin: E-Mail-Adresse kann man im im Nicht-Standard-Parameter "username" (s. O365; neben AuthReqest und Relaystate) an IdP übergeben und mit ServletFilter vor-ausfüllen lassen. Dann muss der IdP natürlich Login mit E-Mail erlauben. 
 + 
 +Bernd: Auch direkt am eduID IdP anmelden - user-centric, auch innerhalb der Organisation jedem User überlassen, ob direkt oder lokal oder beides 
 + 
 +Gerrit: User kann edu-ID erzeugen, der noch an keiner Uni ist? --> ja. User an der SBB haben keine bestimmte Mail-Domain... 
 + 
 +Wolfgang: MFA?? geschieht lokal, und dann muss auch der erste Faktor lokal sein! Oder ganz SSO und MFA am eduID IdP abhandeln. 
 + 
 +Bernd: wenn alle lokalen Dienste einer Uni eduID unterstützen, kann man den lokalen IDP wegoptimieren... -> Wolfgang: wie in Feide 
 + 
 +Thorsten: Autorisierung am SP ist dann aber schwierig. 
 + 
 +Charme für kleine Unis: Nur LDAP/SCIM zu eduID, müssten keinen eigenen IdP mehr haben 
 + 
 +Grundlegendes Modell von Bamberg steht, nur die DS-Implementierung unklar 
 + 
 +Es gibt Modelle, die sowohl Mailadresse als auch Organisations-Auswahl bieten. Kann aber auch verwirrend sein, wenn es direkt nebeneinander steht. 
 + 
 +Thorsten: was hilft im Use Case * (s.o.)? Regelmäßiges Anmelden? 1x pro Jahr Login überprüfen? Mail rausschicken, auch um die Mail zu überprüfen? --> Bernd: s. Nationallizenzen. Vorsicht aber - ähnliche Mails kommen dann auch von Spammern...? 
 + 
 +==== Zusammenfassung ==== 
 +  * Grundlage ist die in Bamberg erarbeitete [[de:aai:eduid:architektur|Architektur]] 
 +  * Sollen sich SPs nur exklusiv mit dem edu-ID-System verbinden können? (edu-ID-IdP nur in der Rolle als Homeless IdP in der eigentlichen Föderation) 
 +    * Dies würde den Discovery Prozess vereinfachen... 
 +    * Es existieren Szenarien, in denen ein gemischtes Modell sinnvoll ist 
 +    * Favorisiert wird also ein zentral gepflegter DS, der neben dem edu-ID-IdP auch die IdPs/Einrichtungen listet, die **nicht** mit dem edu-ID-System verbunden sind 
 +    * Daher ist für den Weg über das edu-ID-System ein zweistufiges Discovery-Verfahren erforderlich  
 +  * Discovery am edu-ID-System 
 +    * Angedacht, dass die User am edu-ID-System eine ihrer hinterlegten E-Mailadressen eingeben und abhängig davon entschieden wird, wie die Authentifizierung erfolgt 
 +    * Wenn keine Affiliation hinterlegt ist, wird lokal am edu-ID-IdP authentifiziert 
 +    * Wenn Affiliations hinterlegt sind 
 +      * ... könnten die User voreinstellen, welcher IdP bevorzugt zur Authentisierung verwendet werden soll (das koennte auch der edu-ID-IdP selbst sein) 
 +      * Es könnte auch isPassive genutzt werden, um zu prüfen, ob der/die Nutzer*in bereits an einem der Heimat-IdPs eingeloggt ist.  
 +      * Falls ein Login erforderlich ist, könnte der/die Nutzer*in evtl. im Subject übergeben werden, damit der IdP die Benutzerkennung voreinstellen kann (bei Username + Passwort Login)  
 +      * (Auswahl der zu übertragenden Affiliation[s] bzw. Affiliation-Daten erfolgt dann im Rahmen der Attributfreigabe) 
 +    * <del>Als Alternative könnte eine traditionelle Einrichtungsauswahl angeboten werden  
 +      * Im UI nicht neben der Eingabe für die E-Mail-Adresse, sondern umschaltbar, um die User nicht zu verwirren</del> 
 +  * Offene Punkte 
 +    * Migrationsszenarien, insbesondere SP-seitig --> Umstellung der Identifier(-Attribute) 
 +      * Agenda-Punkt für [[de:aai:eduid:ws_feb_2010#agenda_im_aufbau|Workshop in Kaiserslautern]] 
 +    * Mechanismen zur regelmäßigen Kontrolle der edu-ID Credentials (Erinnerungsmail, Login mindestens einmal pro Jahr?) --> Verfahren bei SWITCH? Erfahrungen mit demselben?
  • Zuletzt geändert: vor 4 Jahren