Verteiltes Ressourcenmanagement mit der SaxID API FRMS Daniel Schreiber TU Chemnitz, Universitätsrechenzentrum 21. März 2017 1 / 21
SaxID Projekt 1. SaxID Projekt 2. SaxID API 3. Umsetzung 2 / 21
SaxID Projekt Projekt SaxID Projektziele Projekt von 7 sächsischen Hochschulen, später 13 Evaluieren: Vereinheitlichung von Diensten Vereinheitlichung Identitymanagementsysteme einheitlicher einfacher Dienstzugang Dienste sachsenweit anbieten Abstraktionsschicht für Identitymanagement in Sachsen, Metaverzeichnis? Welche Dienste? Dienstetypisierung gefördert aus SMWK Initiativbudget 3 / 21
SaxID Projekt Festlegungen Dienste klassifiziert reine Webdienste Webdienste mit weiteren Schnittstellen Windowsdienste Unixdienste Metaverzeichnis verworfen einheitliches IdM verworfen bestehende Infrastruktur nutzen DFN AAI Eduroam 4 / 21
SaxID Projekt DFN AAI an der TU Chemnitz Strategie: alle neuen Dienste mit Shibboleth oder Kerberos Authentifizierung aktuell 147 Serviceprovider produktiv, davon 82 im URZ IDP: SimpleSAMLphp SP: Apache + mod_shib Shibboleth SP in Plattformmanagement integriert 5 / 21
1. SaxID Projekt 2. SaxID API 3. Umsetzung 6 / 21
Motivation Nutzer: Ich will es bequem und einfach. Mir ist egal, wer mir den Dienst erbringt. Ich will ein Portal, wo ich meine Ressourcen verwalten kann. Betreiber: Ich will erprobte Technologie Ich will nicht jeden Dienst anbieten müssen, der gerade in Mode gekommen ist Ich will Ordnung. Keine überflüssigen Accounts/Daten. Wann kann man Ressourcen wieder freigeben? Wie kann ich fremde Dienste in mein Service-Management-Portal integrieren? Wie integriert man Dienste so, dass sich Dienste, die von einer Partnereinrichtung erbracht werden, so anfühlen wie von der Heimathochschule? 7 / 21
Warum nicht nur DFN AAI nutzen? Authentifizierung: DFN AAI Fragestellungen bei Deprovisionierung: Ist Account noch gültig? (z.b. mit Attribute Query) Können Daten des Accounts gelöscht werden? Push: Konfiguration des Dienstes im Servicemanagement der Heimathochschule Reporting: Wieviele Ressourcen belegen sie dort? Welche Dienste von Fremdeinrichtungen nutzen meine Nutzer? 8 / 21
Lösungsansatz: SaxID API verteilte Datenbank Synchronisiert Wissen über Ressourcenzustand und Nutzer Datensparsamkeit als Designziel pro Instanz folgende Daten: Daten eigener Nutzer, die eigene und fremde Dienste nutzen Daten fremder Nutzer, die eigene Dienste nutzen Schnittstelle zwischen Serviceprovider und Heimateinrichtungen keine GUI für Endnutzer 9 / 21
API Betriebsmodell Einrichtung B Einrichtung A IDM B IDM A Synchronisation API B SP 1 B SP 1 A API A Synchronisation SP 2 A Synchronisation API C IDM C Einrichtung C 10 / 21
Einsatzszenario Einrichtung A (a.edu) Einrichtung B (b.edu) IdP A Nutzer A Shibboleth u@a.edu SP 1 B via REST FRMS A Synchronisation FRMS B Abbildung: Initialer Ablauf schematisch 11 / 21
Einsatzszenario Einrichtung A (a.edu) Einrichtung B (b.edu) IdP A Nutzer A Shibboleth u@a.edu SP 1 B via REST FRMS A Synchronisation FRMS B Abbildung: Ablauf im Betrieb 12 / 21
Datenmodell ServiceProvider UUID Name Realm Expiry Date Resource UUID SP eppn Expiry Date Deletion Date Attribute Name Default Value Value Resource Version Vector (SP, IdP) Version Vector Priority 13 / 21
Synchronisationsprotokoll Datenaustausch per REST/JSON Ressourcen/SPs per UUID identifiziert Attributaktualisierung auf beiden Seiten möglich Konflikterkennung über Versionsvektor pro Attribut Vorrangregel für Konfliktlösung wechselseitige Authentifizierung per Shared Token URI Schema /res POST Ressource registrieren /res/<uuid> GET/PUT/DELETE Ressourcendetails /services/<uuid> GET Serviceprovider /health GET Monitoring 14 / 21
Dedeployment Steuerung komplett über Heimateinrichtung IdM setzt Ablauf- und Sperrdatum SP muß nicht zwischen Nutzerstatus abgelaufen/gesperrt/... unterscheiden SP vergleicht Expiry Date Ressource blockieren SP vergleicht Deletion Date Ressource löschen 15 / 21
Anforderungen, Laufzeitumgebung Python 2.7 oder >= 3.4 MySQL oder PostgreSQL WSGI kompatibler Webserver z.b. Apache Linux, FreeBSD 16 / 21
Umsetzung 1. SaxID Projekt 2. SaxID API 3. Umsetzung 17 / 21
Umsetzung Beispiel SP: GitLab Event: Neuer Nutzer nutzt Gitlab System Hooks neuer Nutzer: Gitlab macht POST-Request an definierten URI eigenes Djangoprojekt übersetzt in SaxID API Regulärer Betrieb Synchronisation zwischen GitLab und SaxID API per Cronjob nutzt GitLab REST API 18 / 21
Umsetzung Beispiel SP: Nextcloud Shibboleth Integration über eigene Nextcloud App Sync Client über Gerätepasswörter oder eduroam Authentifizierung SaxID-Integration über eigene Nextcloud App Event: Neuer Nutzer Listener auf Nextcloud Hook registriert Nutzer in SaxID API Regulärer Betrieb Synchronisation zwischen Nextcloud und SaxID API per Cronjob Nutzung der Nextcloud Provisioning API Konfiguration der Quota über IdM/Service Management der Heimateinrichtung 19 / 21
Umsetzung Aktueller Stand Umsetzung TU Chemnitz TU Dresden IDM IDM GitLab API Synchronisation API HPC Nextcloud API IDM API IDM API IDM HS Mittweida HTWK Leipzig TU Freiberg 20 / 21
Umsetzung Projektergebnisse SaxID API an mehreren Hochschulen produktiv GitLab GitLab-Dienst wird gut angenommen, über 500 Nutzer, davon mehr als 100 anderer Einrichtungen durchweg positives Feedback Datenschutz ist bei Nutzern relevantes Thema Public Cloud Dienste werden genutzt, wenn es keine Alternativen gibt nächste Schritte weitere Dienste sollten integriert werden: Produktivbetrieb Nextcloud (TUC) Integration HPC (TU Dresden) Integration Sharepoint (HTWK Leipzig) Integration weiterer Hochschulen Verbesserung der Dokumentation Initialisieren von Partnerbeziehungen sollte einfacher werden 21 / 21