SaxID föderatives IDM in Sachsen

Transkript

1 Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) SaxID föderatives IDM in Sachsen Herbsttreffen des ZKI AK Verzeichnisdienste am 01. und 02. Oktober 2015 in Heidelberg ZIH-PMC-IDM (Moritz Hesse) Datum:

2 Agenda Hochschulübergreifende Accountnutzung Ein breites Fundament: Extensive Ist-Erhebung SaxID = DFN-AAI +? SaxID-LDAP-Proxy und SaxID-API: Zwei Sonderlösungen Die politische Dimension 2

4 Ziel: Übergreifende Nutzung lokaler Konten Ausgangssituation Zielsetzung SaxID Hochschulübergreifende Verwendung der Benutzerkonten momentan nicht möglich Registrierung bei fremden Diensteanbietern erforderlich Erhöht Zusatzkosten, Aufwand und Fehlerpotential etc. Heterogene IDMS-Landschaft trotz z.t. gleicher eingesetzter Software Seit 2011 Kooperation zwischen TU Dresden und Uni Leipzig zur gemeinsamen IDM-Beschaffung für Nutzer/Anwender Übergreifende Dienstenutzung ohne Account an fremder Einrichtung Verringerung von Nutzungsbarrieren und Intensivierung der Dienstenutzung Steigerung der Qualität von Forschung und Lehre für Hochschulen Nutzung von Synergieeffekten; Steigerung von Effektivität und Effizienz Stärkung der Marktposition gegenüber Anbietern (vergünstigte Bezugskonditionen) Erweiterung von Diensten und Funktionen 4

5 Beteiligte SaxID-Hochschulen ~99% Studierende adressiert TU Dresden Uni Leipzig TU Chemnitz HTWK Leipzig TU BA Freiberg HTW Dresden HS Zittau/Görlitz WH Zwickau HS Mittweida HfBK Dresden HfM Dresden HGB Leipzig HMT Leipzig Hinweis: Beteiligt sind alle sächsischen Hochschulen in staatlicher Trägerschaft, bis auf die Palucca Hochschule für Tanz Dresden, die Fachhochschule für öffentliche Verwaltung und Rechtspflege Meißen und die Hochschule der Sächsischen Polizei (FH) Rothenburg/Oberlausitz. 5

6 SaxID nicht das einzige IDM-Föderationsprojekt! Baden-Württemberg bwidm ( ) Bayern Berlin Brandenburg Bremen Hamburg Hessen Mecklenburg-Vorpommern Im Rahmen der Initiative "Bayern digital" (Programm "Digitaler Campus Bayern") Mitglied DFN-AAI Uni Potsdam Mitglied DFN-AAI; "Derzeit [ ] keine Pläne oder Projekte, ein föderiertes IdM aufzubauen."; mittelfristig aber vorgesehen Mitglied DFN-AAI Mitglied DFN-AAI Niedersachsen Nds-AAI (seit 2009) Mitglied DFN-AAI; geplant "im Rahmen des neu eingerichteten Hessen-Netzes" Uni Greifswald, Rostock und HS Wismar Mitglieder DFN-AAI; "weitere Bestrebungen [ ] nicht geplant." Nordrhein-Westfalen Rheinland-Pfalz Saarland Mitglied DFN-AAI Mitglied DFN-AAI Nutzung DFN AAI "deutlich auszuweiten", aber aktuell kein Bedarf für "eigenes föderiertes IDM" vorhanden. Keine DFN-AAI-Mitgliedschaft Sachsen SaxID (Projekt ongoing, geplant bis Ende 2016) Sachsen-Anhalt Schleswig-Holstein Mitglied DFN-AAI Mitglied DFN-AAI Thüringen CODEX Meta Directory (vor 2012) Legende abgeschlossen ongoing geplant kein föd. Landes-IDM keine Informationen Quellen: Anfragen Ministerien/Rechenzentren; DFN-Metadaten 6

8 Extensive Ist-Erhebung für alle 13 Hochschulen erfolgt Ist-Architekturen IDMS-Steckbriefe Bildungsvorschriften Ist-Architekturen IDM-Systeme und Umsysteme (Quell- und Zielsysteme) IDMS-Steckbriefe mit wesentlichen technischen und organisatorischen Informationen Bildungsvorschriften zur Erzeugung von Benutzernamen 4 Datenausprägungen 5 Dienstekatalog Datenausprägungen von Nutzern und Vertragsobjekten in den IDM-Systemen Angebotene IT-Dienste sowie deren SaxID-Relevanz 8

9 Einheitliches Architekturmodell vorgeschlagen Evaluierung Modellentwurf Konsolidierung IDM Beschaffung von Informationen Analyse verfügbarer Informationen aus bestehenden Hochschul- Architekturen Beschaffung weiterer Informationen zu IDM-, Quellund Zielsystemen Entwurf einheitliches Modell Identifizierung gemeinsamer Funktions- und Prozessblöcke ("IDM-Wertschöpfungsmodell") Entwurf einer einheitlichen Notation zur Darstellung der Ist-Architekturen Vereinheitlichung der Modelle Überführung der bereitgestellten Schemata in neues Einheitsmodell Ziel: Schnelle Identifizierung von Konsolidierungs- und Synergiepotentialen Einheitliches Modell erleichtert Abstimmung 9

11 Föderierte AAI bereits im Einsatz mit Einschränkungen Herkömmliches Verfahren Shibboleth WebSSO Uni A Uni B Registrierung Kopie Zugriff Dienst Benutzeraccount bei fremder Einrichtung erforderlich Dateninkonsistenzen, mehrfache Datenhaltung, Aufwand für Registrierung, Lizenzkosten etc. Kein Fremdaccount erforderlich, stattdessen übergreifende Authentifizierung und Autorisierung Shibboleth bereits weltweit im Einsatz (Deutschland: DFN-AAI) Aber: Shibboleth WebSSO nicht ausreichend für alle Szenarien SP: Service Provider; IdP: Identity Provider 11

12 4 Szenarien identifiziert, in denen WebSSO unzureichend "ARP-Plus"-Webdienste Unix-Dienste Microsoft-Dienste Proprietäre Webdienste Komplexe Berechtigungen oder Rollen? Webdienst/ Shibboleth SP Unix-Dienst (kein Web/SP) MS-Dienst (kein Web/SP) Proprietärer Dienst??? Shibboleth IdP ARP: Attribute Release Policies; SP: Service Provider; IdP: Identity Provider 12

13 1 Webdienste mit Shibboleth und "ARP-Plus"-Webdienste Problem Lösungsansatz Komplexe Berechtigungen oder Rollen Shibboleth implementiert proprietäre Attribute Release Policies (ARP) Implementierung einer geeigneten Shibboleth-Erweiterung, z.b.? Webdienst/ Shibboleth SP Shibboleth IdP nur für einfache Szenarien ausreichend komplexe Berechtigungsstrukturen oder Rollenmodelle nicht realisierbar XACML PONDER EPAL P3P E-P3P 13

14 2 Unix-nicht-Webdienste und Shibboleth Problem Lösungsansatz Unix-Dienst (kein Web/SP)? Unix-Dienste häufig keine Webdienste können nicht als Shibboleth Service Provider (SP) implementiert werden Erweiterung/Anpassung erforderlich 1. Shibboleth mit PAM 1 und SAML ECP 2 2. per Shibboleth erzeugte, temporäre lokale Accounts, dann Remotenutzung mit diesem dienstlokalen Account 3. zentraler LDAP-Proxy 4. lokaler LDAP-Proxy Shibboleth IdP (1) Pluggable Authentication Module; (2) Enhanced Client or Proxy 14

15 3 Microsoft-nicht-Webdienste und Shibboleth Problem Lösungsansatz MS-Dienst (kein Web/SP)? Shibboleth IdP Microsoft-Dienste häufig keine Webdienste können nicht als Shibboleth Service Provider (SP) implementiert werden analog zu Unix- Diensten: Erweiterung/ Anpassung erforderlich 1. Windows-AD- Vertrauensstellung 2. per Shibboleth erzeugte, temporäre lokale Accounts; Remotenutzung mit dienstlokalen Account 3. zentralistische Windows-AD- Gesamtstruktur 4. per Shibboleth initiierter Download Installer/Config 15

16 4 Proprietäre Webdienste mit eigener Nutzerverwaltung Problem Lösungsansatz Proprietärer Dienst? Closed Source (Web-) Applikationen/ proprietäre Software fehlende Möglichkeit zu Implementierung als Shibboleth SP eigene Nutzerverwaltung vorhanden Shibbolethierung per "Hooking" Umleitung auf Login- Hooker umgeleitet implementiert Shibboleth SP Hooker startet Login am Webdienst per Web Scraping Übergabe gestarteter Session Shibboleth IdP Hinweis: Methode von Hrn. Steffen Dach (TU Bergakademie Freiberg) konzipiert und erprobt; Details von dort zu erfragen 16

17 SaxID = DFN-AAI +? SaxID ist also DFN-AAI + Lösungen für Szenarien, in denen Shibboleth WebSSO nicht ausreicht + SaxID-API für Reportingzwecke + Federation Access Policy mit sächsischem Scope 17

19 SaxID-LDAP-Proxy: Systemarchitektur SLES Benutzer ruft Webdienst auf Anfrage wird von Simple- SAMLphp abgefangen Symfony2 apache und via Fremd-IdP authentifiziert SaxidLdapProxy 2 5 SimpleSAMLphp (Service Provider) 3 4 Shibboleth IdP (fremd) 4. 4 Attribute werden an SP zurückgeliefert 5. 5 und an LDAP-Proxy- 6 Webdienst weitergereicht 6. 6 Attribute werden in LDAP- openldap 7 Dienst mit LDAP- Authentifizierung System eingetragen Aber: Kein SSO, keine passwortlose Auth., keine autom. Deprovisionierung 19

20 SaxID-API: Controlling und Reporting in der Föderation Aus Teilprojekt "owncloud" entstanden Bedarf für Übertragung zusätzlicher Informationen (owncloud: z.b. Quota) IDMS Universität A IT Landscape Universität B IT Landscape IDMS IDMS Universität C IT Landscape Außerdem Informationen für Deprovisionierung und Dienstenutzung (Controlling, Reporting, Accounting) Dezentral an jeder Heimateinrichtung Entwurf für REST-API-Protokoll vorhanden Entwicklung ongoing SaxID API SaxID API SaxID API URI Schema /sp/ /sp/<name>/resources/ /sp/<name>/resources/<uuid> /sp/<name>/attributes/ /idp/<name>/users/ /idp/<name>/users/<eppn>/resources/ /idp/<name>/resources/ 20

22 Vertragswerke regeln Zusammenarbeit in Föderation Plugin/Interface/Modul Anforderungsdokument Föderationsvereinbarung Technische Lösung (in Form von lauffähigen Prototypen) idealerweise ein universell einsetzbares Plugin Dokument mit funktionalen und nichtfunktionalen Anforderungen an eine zukünftige SaxID-Lösung Vereinbarung zwischen teilnehmenden Hochschulen, welche die Zusammenarbeit sowie technische und rechtliche Details regelt Team A Team B Spezielle Lösung Team Erkenntnisse Codex Thüringen Erkenntnisse bwidm DFN-AAI Attributsschema UL TUD TUC Spezielle Lösung Spezielle Lösung SaxID-Anforderungen TUBAF HSZG Plugin/Interface/ Modul Bottom Up Anforderungsdokument Föderationsvereinbarung 22

23 Was ist bei Föderationsvereinbarung zu beachten? Technischen Fragestellungen nicht wesentliche Problematik; Herausforderung ist Zusammenarbeit zwischen Mitgliedern der Föderation Basis ist Vertrauen zwischen Föderationsmitgliedern IdP muss SP vertrauen können, da dort im Zweifelsfall die Eingabe des Passworts z.b. bei ECP abgegriffen werden kann! SP muss Authentifizierungsresultat des IdP vertrauen können! Klare Regelungen erforderlich, um nachhaltige und konfliktarme/-freie Zusammenarbeit zu ermöglichen Vertragliche Regelung der Föderation: Organe/Gremien, Pflichten und Rechte, Ausschluss von Mitgliedern, Haftung, Kosten/Gebühren Relevanten Attribute zu definieren: so wenig wie möglich, so viel wie nötig 23

24 In eigener Sache: ZIH-Kolloquium NUR EIN SPOT 24

25 ZIH-Kolloquium: Call for Papers Ralph Müller-Pfefferkorn Foto: Detail from Raffael's painting "Madonna Sixtina" (in Gemäldegalerie Alte Meister in Dresden) from Bert Kaufmann (CC BY 2.0) 25

26 Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) SaxID-Ansprechpartner Dr. Björn Gehlsen Stellvertretender Direktor / COO Zellescher Weg 12-14, D Dresden bjoern.gehlsen@tu-dresden.de Telefon: