~~NOTOC~~
====== Arbeitsgruppe WAYF ======
{{INLINETOC 2}}
**Zweck: Vorbereitung des Workshops im Februar 2020** 

(Zurück zur [[de:aai:eduid:ws_feb_2010|Workshop-Seite]])

**Thema:** WAYF ("Affiliation Chooser") am edu-ID-IDP (Vorschlag: über E-Mail-Adresse)

**Koordination:** Bernd Oberknapp

**Teilnehmende: (bei Interesse bitte eintragen)** 
  *<del> David H.</del>
  * 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?