DARIAH AAI 1.0 und 2.0 und was das mit Hochschulkooperation zu tun haben könnte

Transkript

1 DARIAH AAI 1.0 und 2.0 und was das mit Hochschulkooperation zu tun haben könnte ZKI AK Verzeichnisdienste Heinrich-Heine-Universität Düsseldorf, Peter Gietz, DAASI International

2 Agenda Kurzeinführung DARIAH DARIAH-AAI 1.0 EduGain-Logins und eigene Accountdatenbank gleichzeitig verwalten Probleme mit edugain Terms of Use DARIAH-AAI 2.0 AARC Blue Print Architecture und das Proxy-Modell Vereinfachungen für DARIAH Service Provider DARIAH-AAI und Hochschulkooperationen 1. 2 / 31

3 DARIAH Kurzeinführung DARIAH: Digital Research Infrastructure for the Arts and Humanities Im Rahmen der ESFRI (European Strategy Forum on Research Infrastructures) mit einem ERIC seit 2014 Schwesterprojekt zu CLARIN DARIAH-EU ist eine europäische Infrastruktur für die Geisteswissenschaftler*innen, die Algorithmen für den Erkenntnisgewinn einsetzen (Digital Humanists) Infrastruktur im weitesten Sinne: technische Infrastruktur: Basisdienste, Software, Verwaltung Methodensammlung, Input für DH Curricula, etc. Ein Netzwerk von Menschen Gemeinsame Aktivität von Techniker*innen und geisteswissenschaftlichen Forscher*innen, die mit virtuellen Forschungsumgebungen arbeiten DARIAH-DE ist die deutsche Aktivität im Rahmen von DARIAH 3 / 31

4 Virtuelle Forschungsumgebungen in den Geisteswissenschaften 4 / 31

5 DARIAH AAI / 31 Seit 2006 betreibt DARIAH-DE eine produktive AAI, die es Forscher*innen aus der ganzen Welt erlaubt, sich an DARIAHDiensten anzumelden Entweder mit dem Account Ihrer Heimatorganisation Oder über einen dedizierten DARIAH-Account Features: Gruppenbasierte Authorisierung über verschiedene Dienste Single Sign-On DARIAH-DE Dienste sind alle angeschlossen Im Rahmen der DARIAH-EU WG FIM4D werden Dienste aus anderen DARIAH-Ländern angeschlossen

6 DARIAH AAI 1.0 MPCDF 6 / 31

7 DARIAH AAI 1.0 ACHTUNG: Kooperation! (zwischen Max-Planck-Rechenzentren) Gesellschaft für wissenschaftliche Max Plack Computing and Data Facility Datenverarbeitung, Göttingen (früher RZ Garching) 7 / 31

8 Föderation Sammlung (Mitgliederverzeichnis) von Organisationen Genauer Sammlung von Zertifikaten aller Server, die in der Föderation agieren: Identity Provider (IdP) und Service Provider (SP) Erlaubt Teilen von Resourcen über Organisationsgrenzen hinaus mit SSO als Zusatzfeature Basiert heute auf SAML (Security Assertion Markup Language) Nachfolgertechnologie wird gerade spezifiziert (OIDC Fed) Switch.ch 8 / 31

9 Interföderation edugain DFN-AAI edugain Metadata Switch-AAI HAKAI 9 / 31

10 Interföderation edugain 10 / 31

11 DARIAH AAI Ziele Benutzer*innen von DARIAH-Diensten (SPs) sollen sich über ihre Heimatorganisation (campus IdP) authentifizieren Alle DARIAH-Dienste sollen zentral verwaltete Autorisierungsinformationen bekommen, z.b.: memberof: geobrowser-administrators, memberof: dariah-de-coordination-office DARIAH benötigt Informationen über die einzelnen Benutzer*innen: Hat DARIAH Terms of Use bestätigt Hat service-spezifische Terms of Use bestätigt Ist Teil der Forschungscommunity (durch Domain der -Adresse, oder Nachweis) Name (Autorenschaft von Beiträgen) und Kontaktdaten Informationen, die nicht von Campus-IdPs geliefert werden, müssen nachträglich erhoben werden Hat die Benutzer*in keine Heimatorganisation, die Teil der Föderation ist, oder dessen IdP noch nicht einmal eine SP-übergreifende ID (eppn oder eppi), sondern nur epti ausgeben, wird ein dedizierter DARIAH-Account angelegt 11 / 31 Leider augenblicklich die Regel eppn: eppi: epti: edupersonprinciplename edupersonpersistantid edupersontargetedid

12 DARIAH AAI 1.0

13 Warum DARIAH AAI 2.0? Der Aufwand, einen Dienst anzuschließen war wegen der vielen Aufgaben des SPs kompliziert Weiterleitung zum Discovery Service Attribut-Aggregation Attributcheck, Terms-of-Use-Check Weiterleitung zum Registrierungsdienst Zukünftige Anforderungen, wie z.b. Account-Linking Im Rahmen des EU-Projekts AARC wurde eine Blueprint-Architektur entwickelt, um AAIs zu homogenisieren und den Betrieb zu vereinfachen 13 / 31 Zentrales Element ist hierbei ein Proxy Proxy übernimmt zentral Funktionen, die bisher beim SP angesiedelt waren Dies macht den Anschluss eines Dienstes and die DARIAH-AAI wesentlich einfacher Aus einer epti wird eine SP-übergreifende ID!

14 DARIAH AAI 2.0 Proxy SP Proxy IdP Resource Resource SP SP Resource SP

15 DARIAH AAI / 31

16 DARIAH AAI 2.0 Das Proxy-Modell ist konform mit der AARC JRA1 Blueprint Architecture Ist seit July 2018 produktiv Schon vor dem Proxy waren viele Dienste angeschlossen Jetzt, da es wesentlich einfacher ist, rechnen wir mit vielen weiteren Diensten Zukünftige Anforderungen werden einfacher, weil zentral, lösbar: Account-Llinking SRTIFY/SNCTiFY Der Proxy macht es auch einfacher mit anderen Infrastrukturen, wie z.b. EGI zu interagieren EGI interoperation PoC läuft bereits DARIAH-AAI bereit für EOSC! Über den Proxy können wir auch mit edupersontargetedid auskommen 16 / 31

17 Anschluss von Diensten Fast jede SAML Service Provider Programmbibliothek kann verwendet werden Oder Anschluss an einen Shibboleth SP über HTTP Environment-Variablen Der SP muss nicht mehr in der Föderation angemeldet werden, in der Föderation ist nur der Proxy Es müssen also nur Metadaten mit dem Proxy ausgetauscht werden Allerdings müssen Policy-Versprechungen, die der Proxy in der Föderation macht, auch vom einzelnen SP eingehalten werden! Der Proxy sorgt für: Weiterleitung zum IdP Discovery Verbindung nach edugain Sammelt alle Attribute für die SPs 17 / 31 von (Campus-) IdP(s) Registrierte Attribute vom DARIAH IdP Terms-of-Use-Informationen und Gruppenmitgliedschaften

18 DARIAH AAI Proxy-Innereien 18 / 31 Der DARIAH AAI Proxy basiert auf der Open Source Software Shibboleth (sowohl IdP als auch SP): IdP Komponente ist verbunden mit allen DARIAH Diensten, bzw. deren SP SP Komponente ist verbunden mit allen IdPs in edugain. Diese beiden Komponenten sind so zusammengefügt, dass der AAI Proxy alle Daten von edugain IdPs an alle DARIAH SPs weiter gibt

19 Nicht nur ein Proxy Der DARIAH AAI Proxy macht auch noch mehr als Attributweitergabe: Checken ob der edugain user im DARIAH-LDAP registriert ist und falls nicht an das DARIAH Self-Service weiterleiten Checken, ob die DARIAH Nutzungsbedingungen akzeptiert wurde aber auch etwaige dienstspezifische Nutzungsbedingungen 19 / 31 Schlägt auch an, wenn es eine neue Version der Bedingungen gibt Anreicherung der Attribute mit Mitgliedschaftsinformationen zu Autorisierungsgruppen, die vom Dienst für Zugriffskontrolle genutzt werden kann

20 Terms of Use Check 20 / 31

21 DARIAH Self-Service Erweiterungen Registrierungg von Benutzer*innen, die sich über sie edugain metaföderation ( Campus IdP) authentifizieren Beantragen eines DARIAH-Accounts, falls kein IdP bei der eigenen Organisation vorhanden Ermöglicht das akzeptieren der Nutzungsbedingungen Verwaltung der eigenen Daten Zentrale Gruppenverwaltung: 21 / 31 Editieren der Mitgliedschaften, wenn Nutzer*in Owner der Gruppe ist Wenn bereits Mitglied: Mitgliedschaft austragen Wenn noch kein Mitglied, abhängig von der Gruppe entweder Mitgliedschaft Beantragen (muss genehmigt werden), oder Mitgliedschaft eintragen (muss nicht genehmigt werden)

22 DARIAH Self-Service: Account beantragen 22 / 31

23 DARIAH Self-Service: Registrierung Targeted / Persistent ID 23 / 31

24 DARIAH Self-Service: Eigene Daten verwalten 24 / 31

25 DARIAH Self-Service: Gruppenverwaltung 25 / 31

26 Benutzerzahlen August / 31 > 4630 DARIAH-Nutzer > 390 DARIAH-Nutzer von 72 IdPs aus edugain 322 Benutzergruppen Ca. 85 Projekte

27 Was hat das jetzt mit Hochschulkooperation zu tun? Leider nur wenig, aber: Hochschulen kooperieren miteinander in Forschungsprojekten, so auch in DARIAH-DE DARIAH-DE arbeitet zusammen mit CLARIN-D an einer nachhaltigen Infrastruktur für die Geisteswissenschaften Hier hilft Forschungsprojektförderung nicht 27 / 31 Alternativen müssen her, z.b. Finanzierung nicht über FTEs Rechenzentren müssen in der Lage sein, Rechnungen für Ihre Dienste zu stellen Weiterentwicklung geht mit Projektförderung, Betrieb nicht Alle schauen auf die NFDI (Nationale Forschungsdaten Infrastruktur)

28 Beispiel DARIAH Repository 28 / 31

29 Beispiel DARIAH Repository Die Infrastruktur ist so angelegt, dass auch gleiche Dienste (DARIAH Storage API) in verschiedenen Instanzen von verschiedenen Rechenzentren betrieben werden sollen Datenreplikationsverbund Es müssen SLAs definiert werden 29 / 31 Verschiedene Bausteine solcher komplexen Infrastrukturen werden von verschiedenen Hochschulen betrieben Dienste müssen gebrokert werden können DARIAH einfrastructure Service Unit (DeISU)

30 DeISU Vertragsmodell 30 / 31

31 Mehr Infos:

32 Central Policy Decision Point If more than one system trusts an access policy it makes sence to have a central policy decision point Manage the access rules only once Policy Enforcement Point doesn t have to deal with managing and evaluating access policy Just needs to get access decisions from the PDP via simple and standardized protocols DARIAH uses the RBAC compliant open-source PDP didmos Decision Point in combination with apis OAuth2 Authorization Server

33 DARIAH PDP 33 / 31

34 PDP - Flow 0: Session mit einem OAuth2-fähigen Dienst besteht 1: Redirect mit SAML-Login am OAuth2 AS 2: AS erfragt Consent, und schickt Redirect mit Token (evtl AuthZ Code noch davor) zurück zum Dienst 3. Dienst setzt Token ein, Resource: StorageAPI 4. StorageAPI holt sich UserID aus Token 5. StorageAPI fragt PDP: checkaccess(userid,read/write/operationabc,dateixyz) 6. Interne Token-Validierung (PDP beim AS) Auslieferung der DateiXYZ an Dienst 34 / 31

35 Connect the SP to the DARIAH AAI

36 Set up Trust with the AAI Proxy Download the DARIAH AAI Proxy's Metadata file like this (mind the capital "-O") wget -O / etc/shibboleth/dariah-proxy-idp.xml Locate the MetadataProvider section in /etc/shibboleth/shibboleth2.xml and add a row: <MetadataProvider type="xml" file="dariahproxy-idp.xml"/> 36 / 31 Send your own SP's metadata to register@dariah.eu (from

37 Further SP Configuration In /etc/shibboleth/shibboleth2.xml, set the SP to direct login using <SSO entityid=" Use the following ID preference order REMOTE_USER="eppn unique-id" Enable edupersonuniqueid in /etc/shibboleth/attribute-map.xml: <Attribute name="urn:oid: " id="unique-id"> <AttributeDecoder xsi:type="scopedattributedecoder"/> </Attribute> 37 / 31

38 Attributes in the DARIAH AAI Released by default: eppn, affiliation, unscoped-affiliation, entitlement Add and use unique-id for personalization (see previous slide) Configure in /etc/shibboleth/attribute-map.xml, by uncommenting: cn (CommonName), givenname, sn (surname), displayname, preferredlanguage, o (Organization), mail, schaccountryofcitizenship DARIAH-specific Attributes, by adding: <Attribute name="urn:oid: " id="ismemberof"/> <Attribute name="urn:oid: " id="dariahrole"/> <Attribute name="urn:oid: " id="dariahtermsofuse"/> 38 / 31

39 Attributes from Campus IdPs Adapt attribute-policy.xml to accept any scope Remove the Scope Checking stanza for affiliation and eppn <afp:attributerule attributeid="affiliation"> <afp:permitvaluerule xsi:type="and"> <RuleReference ref="edupersonaffiliationvalues"/> <!-- accept any scope <RuleReference ref="scopingrules"/> --> </afp:permitvaluerule> </afp:attributerule> [...] <!-- accept any scope for legacy users <afp:attributerule attributeid="eppn"> <afp:permitvaluerulereference ref="scopingrules"/> </afp:attributerule> --> 39 / 31

40 Terms of Use for Service Generally DARIAH AAI ToU must be accepted by anyone using the DARIAH AAI The AAI proxy checks the ToU acceptance A DARIAH Service can have additional ToU Upload your ToU document to the DARIAH Repository, cf. DARIAH ToU: 40 / 31

41 Terms of Use for Service (2) 41 / 31 Then request an authorization group attached with your service's ToU: Log in to the SelfService, and choose Manage Groups "+ new group" (at the bottom of the page) Choose a group name, e.g. myservice-users Put the link to your ToU in the "Remarks" box DARIAH staff will create the group for you