Vorstellung der Studie zu Opensource IdM-Systemen

Transkript

1 Vorstellung der Studie zu Opensource IdM-Systemen Peter Gietz, Markus Widmer DAASI International ZKI-Verzeichnisdienste, Universität Ulm

2 Inhalt Ziele Systemaufbau Ergebnisse Opensource-Systeme Ergebnisse kommerzieller Systeme Schlussfolgerungen Folie 2 von 39

3 Folie 3 von 39 Ziele

4 Folie 4 von 39 SOLL-Zustand

5 Ziele des ZIM Ablösen oder modernisieren der bisherigen Systeme Viele gewachsene Einzel-Lösungen Inzwischen schwer zu warten und zu erweitern Funktionsumfang soll erhalten bleiben Einführen eines IdM-Systems Neues System HIS-LSF Neues Active Directory für Verwaltung Folie 5 von 39

6 Ziele der Studie Überprüfen verschiedener IdM-Systeme auf Grundlage des Konzeptpapiers des ZIM Detaillierte Überprüfung von Opensource-Systemen Übersicht über kommerzielle Produkte Folie 6 von 39

7 Ziele der Studie Erstellen eines Fragenkatalogs Kann die benötigte Datenstruktur abgebildet werden Steht ein ausreichender Funktionsumfang zur Verfügung Import / Export Provisionierung Verwaltung im IdM Können die benötigten Prozesse abgebildet werden Empfehlung eines Systems mit Übersicht über die zu schließenden Lücken Folie 7 von 39

8 Folie 8 von 39 Systemaufbau

9 Übersicht CSV-1 LSF Kandidat LDAP Übersicht AD Folie 9 von 39

10 Evaluation Opensource Produkte Wurden (bis auf didmos) im Labor auf virtuellen Maschinen aufgebaut Zusätzlich wurden ein OpenLDAP und ein Active Directory aufgebaut Anschließende Überprüfung gegen den Fragenkatalog Aufteilung auf mehrere Mitarbeiter: midpoint zusammen mit OpenIDM Syncope zusammen mit didmos WSO2 Folie 10 von 39

11 Evaulation kommerzieller Produkte Kommerziellen Produkten wurden anhand öffentlich zugängliche Dokumentation gesichtet und teilweise Interviews mit den Herstellern geführt. Folie 11 von 39

12 Unterteilung des Fragebogens Datenmodell (Datenmengen, Rollenmodell,Organigrammabbildung, Einzelinformationen, wie z.b. Kostenstelle, Auditinformation, etc.) Importschnittstellen (versch. Technologien, Aggregation, automatische Generierung von Datenfeldern, etc.) Exportschnittstellen/Provisionerung (versch. Technologien, Initialbefüllung, komplexe LDAP-Zielstrukturen, Filterung, etc.) Administrative Prozesse (Technik, Funktionalitäten, Massenimport, etc.) Self-Service-Funktionalität (Technik, Funktionalitäten, etc.) Authentifizierung und Autorisierung der Tools (Technologien) Rahmenbedingungen (Lizenzen, Dokumentation, etc.) Folie 12 von 39

13 Relevanz der Fragen Relevanz 3 : Es ist eine zwingende Anforderung an das System. Relevanz 2 : Es ist eine wichtige Anforderung an das System, jedoch kein Ausschlusskriterium. Relevanz 1 : Es ist eine optionale Funktion, die das System nicht erfüllen muss, die aber in späteren Projekten sinnvoll eingesetzt werden könnte Folie 13 von 39

14 Antworten der Fragen : richtig / ja: Die Funktionalität wird vollständig unterstützt und kann über Konfiguration angepasst werden. Da jedes Produkt eine eigene Vorstellung davon besitzt, was als Konfiguration gewertet wird, werden folgende Kriterien vorgegeben: Es wird ein Parameter aus einer Konfigurationsdatei, einer Datenbank oder einem Verzeichnisdienst eingelesen. Datentransformationen über Skripte wie z.b. ECMAScript oder XSLT können als Konfiguration gewertet werden. : richtig / ja: Die Funktionalität wird unterstützt, jedoch nur über einen Work-Around oder durch Nutzung von System-Tools (wie z.b. CRON), jedoch nicht, indem neue Funktionalität hinzu programmiert werden muss. : falsch / nein: Die Funktionalität wird nicht unterstützt. : falsch / nein: Die Funktionalität wird nicht unterstützt, kann aber eventuell implementiert werden oder es wird begründet, warum die Funktionalität als nicht unterstützt eingestuft wird. : Anmerkungen vorhanden : Konnte nicht während der Studie geklärt werden i: Es werden Informationen zur konkreten Konfiguration/Umsetzung angegeben, bzw. es gibt Zusatzinformationen zu Fragen. Folie 14 von 39

15 Fragebogen Siehe externes Dokument Folie 15 von 39

16 Folie 16 von 39 Ergebnisse Opensource-Systeme

17 Syncope Organisation: Apache Software Foundation Version: (2.0.0 als Testversion) Lizenz: Apache License, Version 2.0 Besonderheiten: Rollen können hierarchisch angeordnet werden Bringt Ansätze einer konfigurierbaren Workflow-Engine mit Folie 17 von 39

18 Syncope Dokumentation ist in Ordnung Nicht immer ausführlich Meistens korrekt, an einigen Stellen nicht aktualisiert Wenig Self-Service-Funktionalität Konzentriert sich auf Abgleich von Daten zwischen unterschiedlichen Systemen Ansätze einer Workflow-Engine Übersichtlich Folie 18 von 39

19 midpoint Lizenz: Apache License, Version 2.0 Hersteller: Evolveum Version: Besonderheiten: Kennt Organisationsstrukturen, die hierarchisch angeordnet werden können Zuweisungen von Personen und Accounts können geändert werden Rollenzuweisungen können mit einem Ablaufdatum versehen und die Zuweisung verlängert werden Folie 19 von 39

20 midpoint Gute Dokumentation Probeme bei Provisionierung Active Directory Sehr wenig Self-Service-Funktionalität Konzentriert sich auf Abgleich von Daten zwischen unterschiedlichen Systemen über Konnektoren und darauf definierten Ressource Komplexe Konfiguration Nicht vollständig über Administrationsoberfläche möglich Stellt REST-API zur Verfügung Erweiterung der Self-Service-Funktionen durch Eigenentwicklung Folie 20 von 39

21 OpenIDM Lizenz: Copyright ForgeRock AS. All rights reserved Hersteller: ForgeRock Version: Besonderheiten Eine Person kann mehrere Accounts mit unterschiedlichen Passwörtern besitzen Rollenzuweisungen können zeitlich beschränkt werden Folie 21 von 39

22 OpenIDM Dokumentation ist in Ordnung Nur nach Registrierung bei ForgeRock erhältlich Nicht vollständig Bezieht sich grundsätzlich auf die Enterprise-Version Sehr einfach Installation der Enterprise-Version, Community-Version muss selbst kompiliert werden Wenig Self-Service-Funktionalität Konzentriert sich auf Abgleich von Daten zwischen unterschiedlichen Systemen Probleme bei Provisionierung Active Directory Folie 22 von 39

23 WSO2 (WSO2) Lizenz: Apache License, Version 2.0 Hersteller: WSO2 Besonderheiten: Es können Beschäftigungsverhältnisse mit Personalnummer usw. gespeichert werden Der Zugriff über die SOAP-Schnittstelle von HIS-LSF wird unterstützt Folie 23 von 39

24 WSO2 (WSO2) Sehr gute Dokumentation Viele Screenshots Kein IdM im herkömmlichen Sinn Hauptsächlich ESB-Funktionalität Eher für große Unternehmen geeignet Viele Konnektoren mit Unterstützung von vielen Standards Wenig konkrete Szenarien vorimplementiert, daher oft weniger Punkte in der Studie Folie 24 von 39

25 didmos (DAASI) Lizenz: Apache License, Version 2.0 Hersteller: DAASI Besonderheiten: Baukastenprinzip (wie WSO2) XML-basierter Datenaustausch XSLT-Skripte zur Anpassung für den Kunden Folie 25 von 39

26 didmos (DAASI) Dokumentation noch im Aufbau Keine einheitliche Konfigurationsoberfläche Gesamte Konfiguration über Dateien oder LDAP-Objekte Anpassbares Framework Folie 26 von 39

27 Vergleichsmatrix midpoint Syncope OpenIDM WSO2 didmos Datenmodell (57) Import-Schnittstellen (39) Export und Provisionierung (37) Administrative Prozesse (57) Self-Service (34) Authentifizierung und Autorisierung (9) Rahmenbedingungen (10) Gesamt (243) Folie 27 von 39

28 Bewertung Alle Systeme konzentrieren sich auf einen mehr oder weniger komfortabel zu konfigurierenden Datenabgleich zwischen den einzelnen Systemen. Syncope und WSO2 bringen eine komplexe Workflow- Engine mit, über die Daten-Prozesse abgebildet werden könnten. In midpoint und OpenIdM erlauben Skripte zu hinterlegen, die z.b. beim Anlegen eines Benutzers hinterlegt werden und zusätzliche Operationen ermöglichen. Didmos erlaubt darüber hinaus über Plugin-Interfaces, beliebige Funktionalität (Python, Perl oder XSLT) zu hinterlegen Folie 28 von 39

29 Bewertung midpoint Die Empfehlung dieser Studie fällt auf midpoint, da hier davon ausgegangen werden kann, dass durch Erweiterungen oder zusätzliche Skripte zwar nicht alle, aber viele der Anforderungen umgesetzt werden können. Insbesondere das Self-Service-Portal ist hier jedoch noch deutlich zu wenig umfangreich, wobei dieses durch kundenseitige zusätzliche Entwicklung und Bedienung der midpoint-api abgefangen werden kann. Für den produktiven Einsatz empfiehlt sich eine kostenpflichtige Lizenz, die 3rd-Level-Support mit beinhaltet. Folie 29 von 39

30 Bewertung openidm Als gleichwertig wird aus denselben Gründen wie bei midpoint das Produkt OpenIDM angesehen. Obwohl OpenIDM als Punktsieger hervorgeht, wird besonders das Lizenzmodell als problematisch angesehen, das einen Betrieb ohne Lizenz auch für nichtkommerzielle Einrichtungen nicht erlaubt. Es ist zudem nicht sichergestellt, dass dieses Produkt auf Dauer als Open Source angeboten wird Folie 30 von 39

31 Bewertung didmos Grund dafür, dass didmos nur an dritter Stelle (obwohl von den Punkten an zweiter Stelle) eingeordnet wird ist der schwere Einstieg in didmos wegen der noch fehlenden grafischen Konfigurationsoberfläche und der noch im Aufbau befindlichen Dokumentation. Allerdings ist didmos wegen der sehr offenen Architektur als Framework das Produkt, mit dem im Rahmen eines entsprechenden Projekts am ehesten alle Anforderungen befriedigt werden könnten. Folie 31 von 39

32 Folie 32 von 39 Ergebnisse kommerzieller Systeme

33 NetIQ Rollenhierarchien Rollen in Organigrammhierachien Rollen und Accounts mit automatischem Ablauf Zeitgesteuerter Daten Export REST, SOAP, JDBC, ADSI und CSV-File-Schnittstellen Authentifizierung über LDAP/AD, Oauth und 2Faktor- Authentifizierung HIS-LSF-Anbindung bereits realisiert, aber nicht als SOAP-Konnektor. Folie 33 von 39

34 Ping Klassisches IdM wird nicht unterstützt Bietet Cloud-basierte Verwaltung von Benutzern Konzentriert sich auf Authentifizierung und Autorisierung Rudimentäre Self-Service-Funktionalität Folie 34 von 39

35 IBM Leider nur Kontakt zum First-Level-Support Dokumentation nicht ausreichend aussagekräftig Folie 35 von 39

36 Folie 36 von 39 Schlussfolgerungen

37 Schlussfolgerungen Keines der Systeme erfüllt die Anforderungen voll Es muss entschieden werden, welches Produkt als Basis verwendet und erweitert wird Aufwand kann für die Systeme nicht abgeschätzt werden Es hängt stark von der Implementierung und Strukturierung des Systems selbst ab Alle Systeme konzentrieren sich auf den Abgleich von Daten zwischen unterschiedlichen Systemen Mehr oder weniger passend auf erforderliches Datenmodell Alle bieten Konnektoren zu verschiedenen Systemen, auf denen dann ein Mapping definiert werden kann Folie 37 von 39

38 Zusammenfassung Empfehlung Empfehlung fällt auf midpoint trotz Einschränkungen Self-Service-Funktionalität muss über eigene Implementierung und Bedienung der API umgesetzt werden Prozesse müssen über Skripte erst umgesetzt werden (z.b. Freigabe von Diensten auf Basis von Rollen) Support-Kosten richten sich nach Benutzerzahl Gleichwertig scheint OpenIDM Etwas unklares Lizenzmodell didmos an dritter Stelle schwerer Einstieg ohne Oberfläche wenig Doku Folie 38 von 39

39 Vielen Dank für Ihre Aufmerksamkeit. DAASI International Telefon: