DI Peter Danner peter.danner@egiz.gv.at

EGIZ E-Government Innovationszentrum E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 PROJEKTSPEZIFIKATION ZUGANGSMANAGEMENT MIT EINBINDUNG VON LDAP DI Peter Danner peter.danner@egiz.gv.at Graz, am 29. Dezember 2005 Zusammenfassung: Diese Spezifikation beschreibt die Umsetzung des Zugangsmanagements der Module für Online-Applikationen (MOA). Die Realisierung geschieht in zwei Teilen, wobei zuerst die Zugangsermächtigungen mittels Web-Interface und einer dahinter liegenden Datenbankstruktur realisiert werden und dann die LDAP-Verzeichnisse zur Unterstützung des Datenhaushalts herangezogen werden. Das in dieser Projektspezifikation dargestellte Vorhaben berücksichtigt die Erfordernisse, die sich durch ein Zugangsmanagement unter Verwendung LDAP-Spezifikation von ldap.gv.at als Basis ergeben. Inhaltsverzeichnis Inhaltsverzeichnis 1 Abbildungsverzeichnis 1 1. Einführung 2 2. Umsetzung 4 2.1. User-Management mittels Web-Interface 4 2.1.1. Datenbank-Schema 6 2.1.2. Design und Umsetzung 6 2.2. LDAP-Integration 6 3. Architektur / Komponenten 6 4. Leistungsbeschreibung 7 4.1. Leistungsumfang 7 4.2. Deliverables 8 4.3. Gesamtaufwand 8 Abbildungsverzeichnis Abbildung 1: Einstiegsseite zum Zugangsmanagement 2 Abbildung 2: Kommunikationsstruktur Projekt Zugangsmanagement 4 Abbildung 3: Benutzerkonfiguration 5

- 2-1. Einführung Die Bürgerkarte bietet eine hochqualitative Identifizierung und Authentifikation eines Benutzers. In typischen Betriebsumgebungen sind aber mittelfristig weiterhin Systeme und Online-Applikationen mit konventionellen Mechanismen, wo für verschiedene Anwendungen unterschiedliche Benutzernamen und Passwörter zu verwenden sind, zu unterstützten. Hier sind Single-Sign-On Lösungen sinnvoll, die die Identifikation über Bürgerkarte auf diese Systeme abbildet, sinnvoll. Zum Teil sind diese auf Basis MOA-ID bereits umgesetzt (vgl. externer Zugang zu ELAK IM BUND) Die Verwaltung von Benutzern stellt im Allgemeinen eine beträchtliche Aufwandskomponente dar. Durch das hier vorgestellte einheitliche System wird dieser Aufwand minimiert und bringt große Erleichterungen, zeitliche Ersparnisse und eine Verminderung von Fehlerquellen mit sich. Erreicht wird dies durch die Verwendung von übersichtlichen Formularen mit logischen Zusammenhängen und flexiblen Möglichkeiten. Die Definition von Rollen sind wichtige Maßnahmen um Berechtigungen übersichtlich zu vergeben. Die Verwendung von Gruppen soll eine Zuordenbarkeit zu den Anmeldungsmöglichkeiten schaffen. Auch sollen Passwortänderungen transparent sein und nicht der Notwendigkeit bedürfen, diese in Konfigurationsdateien nachziehen zu müssen. Um die Verwaltung von Benutzern zu unterstützen, ist eine Verbindung zu einen LDAP-Verzeichnis (ldap.gv.at) vorgesehen. Mittels dieses Verzeichnisses können bestimmte Personendaten wie Vorname, Nachname und Geburtsdatum automatisiert übernommen werden. Abbildung 1 zeigt eine mögliche Einstiegsseite zum Zugangsmanagement. Abbildung 1: Einstiegsseite zum Zugangsmanagement

- 3 - Mit Hilfe von Filtern, beispielsweise über die Teilorganisation, können in diesem Bereich global wirkende Konfigurationsteile erstellt und verwaltet werden. So soll etwa für alle Personen die User_ID vorgegeben (z.b. Vorname.Nachname des Email-Zugangs lt. Email Policy), oder dessen Bindungsmodalitäten zur Bürgerkarte konfiguriert werden können. Die Bindung einer Bürgerkarte an eine Online-Applikation kann auf vier Arten geschehen 1. binding = none Es erfolgt keine Bindung an die per MOA-ID identifizierte Person. Nach Identifikation kann sich der Benutzer unter jedem ihm bekannten Account anmelden (sinnvoll etwa für Tests) 2. binding = full Die Bindung des identifizierten Benutzers an die Onlineapplikation ist durch die Konfiguration vorgegeben. Eine Anmeldung wird automatisch durchgeführt. User_ID und Passwort sind in der Konfiguration hinterlegt (Der Vorteil dieser Möglichkeit liegt in der Einfachheit der Verwendung für den Benutzer, da er nach der Identifizierung keine weitere Anmeldung mehr durchführen muss. Diese Lösung kommt dem Look-and-Feel einer Single-Sign-On Lösung sehr Nahe. 3. binding=nomatch Wie binding=full, jedoch wird bei nicht erfolgreichem Passwort beim Benutzer rückgefragt und das Passwort eingetragen. 4. binding = username Der identifizierte Benutzer kann sich nur unter dem ihm zugeordneten Account anmelden. Eine eindeutige Beziehung von Bürgerkarte zum Account der Online-Applikation ist gegeben. Vorteil dieser Variante ist, dass Passwortänderungen nicht zusätzlich in den Konfigurationen nachgezogen werden müssen, sondern immer aktuell geprüft wird. Umgesetzt wird die Bindung durch die Vergabe von Rollen bzw. Gruppen oder durch benutzerspezifische Konfiguration pro Online-Applikation. Die Freischaltung von Anwendungen für den Benutzer soll benutzerspezifisch aber auch für einen Benutzerkreis ermöglicht werden.

- 4-2. Umsetzung Um diese Ziele zu erreichen, wird In einer ersten Phase vor allem das Benutzermanagement von Web-Applikationen umgesetzt, die direkt über MOA-ID ansprechbar sind. Abbildung 2 zeigt die Kommunikationsstruktur und die Möglichkeiten der flexiblen Konfigurationsdatenquellen. Zugangsmanagement Proxy-UMGMT Connector MOA-ID (Proxy) MOA-ID-PROXY-UMGMT MySQL-Datenbank User-Management Webservice und.jsp s MOA-ID-Proxy XML-Konfiguration LDAP ldap.gv.at LDAP andere Verzeichnisdienste LDIF Lightweight Directory Interchange Datei Abbildung 2: Kommunikationsstruktur Projekt Zugangsmanagement andere DBs 2.1. User-Management mittels Web-Interface In der ersten Phase wird eine Web-Applikation erstellt werden, die das Zugangsmanagement umsetzt. Hier wird die LDAP 1 Integration noch aussen vor gelassen, es sollen vor allem flexible Konfigurationsmöglichkeiten erstellt werden. Auf der Einstiegsseite erfolgt die Auswahl der zu manipulierenden Benutzer. Es werden ein oder mehrere Benutzer sowie die betroffenen Anwendungen ausgewählt. In Abbildung 3 wird der Screen Preview eines Formulars dargestellt, über das die Grund- Benutzereinstellungen übergreifend konfiguriert werden. 1 Basis LDAP 2.2.9

- 5 - Abbildung 3: Benutzerkonfiguration Soweit Inhalte aus dem Basisverzeichnis (LDAP) übernommen werden, sind diese nicht veränderbar. Zusätzliche Einträge (ohne LDAP-Basis) können manuell hinzugefügt werden. LDAP-basierte Einträge werden gelöscht, wenn diese Person im LDAP gelöscht 2 wird Anmerkung: bei Abgleich mit einer LDAP-Datenquelle kommt eine Art Master-Slave Beziehung auf, dh. Änderungen im LDAP werden nach manuellem/automatischem/event-gesteuert vom User- Management übernommen und repliziert. Sowohl positive als auch negative Änderungen werden durch dabei vom LDAP-Server (Master) auf das User-Management von MOA-ID (Slave) übernommen. 2 Nur Löschflagge nicht tatsächlich gelöscht

- 6 - Im User-Management von MOA-ID sollten die Einträge auch aufgrund ihrer Ursprungsdatenquelle markiert werden. Besonders LDAP-basierte Einträge sind derart zu markieren, sodass manuelle Änderungen im MOA-ID-Usermanagement zu einer Umstufung von Datenquelle LDAP auf Datenquelle Manuell erfolgt (auf Wunsch und nach Dialog/Rückfrage beim Anwender). So soll bspw. verhindert werden, dass ggf. doppelt vorkommende Benutzer (ist aufgrund derartig manueller Eingriffe denkbar) nicht durch automatischer Replikation zwischen Master-Slave überschieben werden und verloren gehen. Weiters wäre dieses Konzept zu erweitern, sodass selektierte Elemente der User-Einträge auf Wunsch abgeglichen und/oder manuell verändert belassen werden können. 2.1.1. Datenbank-Schema Nach einer genauen Bedarfs- und Realisierungsanalyse wird der Konfiguration ein vorzubereitendes Datenbank-Schema zugrunde gelegt. Dieses Datenbank-Schema ersetzt in weiterer Folge das XML-Schema der Konfiguration des MOA- ID-Proxy. Dabei werden flexible Varianten der Zuordnung umgesetzt werden, die auch erweiterbar sind, etwa: Konfiguration mehrerer Zugänge in einem Schritt, etwa sowohl ELAK-Zugang, als auch SAP-ESS. Erweiterung um weitere Applikationen: Wird ein Portal um weitere Anwendungen erweitert, sollen diese in einem Schritt zugeschaltet werden können. Verwaltung durch Organisationseinheiten: Definition von Benutzergruppen, deren Zugang nur von Berechtigten verwaltet wird (etwa Zugang von Personen eines Ressorts durch das Ressort selbst). ANMERKUNG: Die LDAP-Integration muss auf einer finalen Version der Spezifikation basieren 3. Es wird hier deshalb vor allem auf offensichtliche Inhalte auch künftiger Versionen bezogen. Allfällig weitere Inhalte werden mit der finalen LDAP-Spezifikation einbezogen, sofern diese für das Zugangsmanagement sinnvoll sind (z.b. Organisationseinheit). 2.1.2. Design und Umsetzung Die Formulare und Datenflüsse werden konzipiert, die Web-Applikation umgesetzt 2.2. LDAP-Integration Auf Basis der LDAP Spezifikation 2.2.9 wird die Web-Applikation um die Fähigkeiten der Benutzerauswahl und Datenübernahme erweitert. Es werden Erweiterungen des Benutzer- Managements umgesetzt. ANMERKUNG: Mit der finalen LDAP-Spezifikation wird ein entsprechender Leistungsumfang erstellt. 3. Architektur / Komponenten Es handelt sich bei diesem System um eine Web-Applikation basierend auf Java Server Pages und Java-Servlet Technologie. Zur Kommunikation mit der BKU wird die HTTPS-Bindung verwendet. Auch das Servlet soll nur über HTTPS nutzbar sein. 3 LDAP 2.2.9 ist FINAL und wird von SAP schon verwendet

4. Leistungsbeschreibung - 7 - Die nachfolgend grob beschriebenen Arbeitspakete beinhalten alle Tätigkeiten zur Realisierung des beschriebenen Systems. 4.1. Leistungsumfang Arbeitspakete gem. obiger Beschreibung. a) Entwurf Datenbank-Schema Tätigkeiten: Zu Grunde liegendes Datebank-Schema für Zugangsmanagement erarbeiten. Vorzugsweise aufbauend auf existierenden Standards. Bedarfsanalyse von Umfang, Inhalten und Art der vom Zugangsmanagement benötigten Daten unter Berücksichtigung einer späteren LDAP-Integration. Recherche vorhandener Ansätze/Schemen (z.b. Personendaten-Schema, etc.) und Entwurf des Schemas erstellen. b) Vorschlag für Spezifikationsdokument Benutzerverwaltung auf Basis LDAP Aus dem Projektverlauf allfällig sinnvoll erscheinende Erweiterungen der LDAP Spezifikation vorschlagen. Tätigkeiten: c) Entwurf der Formulare zur Benutzerverwaltung Festlegen der Datenmanipulationsmöglichkeiten. Erstellen der Formulare und Festlegen dessen Verknüpfungen zur Benutzerverwaltung gemäß dem in a) definierten Schema und unter Berücksichtigung einer späteren LDAP- Integration. Tätigkeiten: Festlegen und Einteilen der Eingabebereiche. Festlegen der Zusammenhänge von Datenflüssen. Rohkonzept visuelle Gestaltung der Formulare d) Zugangsmanagement Web-Interface-Applikation Erstellen des Servlets zum Zugangsmanagement basierend auf die Formularkonzepte und Datenflüsse gemäß Punkt b) und dem in a) definierten Schema, vorerst noch ohne LDAP-Funktionalität (je nach Finalisierung LDAP- Spezifikation) Tätigkeiten: Notwendige Java-Klassen erstellen, die dieses Servlet umsetzen, Deploy, Test, div. e) Einbindung von LDAP (ldap.gv.at) Tätigkeiten: Adaptierung und Erweiterung der in Punkt c) erstellten Lösung um unter Verwendung des LDAP-Verzeichnisses die Verwaltung der Benutzer weiter zu vereinfachen. Mit der LDAP-Spezifikation von ldap.gv.at als Ausgangspunkt werden Integrationsmöglichkeiten erarbeitet, festgelegt und dessen notwendige

4.2. Deliverables - 8 - Erweiterungen vorgeschlagen. Umsetzen der Erweiterungen in das in Punkt c) erstellte Servlet bzw. Integration in dessen Java-Klassen. Web-Applikation; installierbar bzw. vorkonfiguriert als Demonstrator für den externen Zugang für MOA-ID Proxy (z.b. ELAK und externen Mailzugang (Outlook Web Access) ) und Vorschlag für Manangement Spezifikation 4.3. Gesamtaufwand Gemäß zuvor skizzierter Tätigkeiten und der dazu abgeschätzten Aufwände ergibt sich folgende Gesamtschätzung: Aktionspunkt Aufwand Priorität a) 7 b) 6 c) 5 d) 16 e) 14 SUMME 48 PT