LÖSUNGEN UND HANDLUNGSEMPFEHLUNGEN FÜR ARCHITEKTURKONZEPTE UND MIDDLEWARE FÜR E-GOVERNMENT-ANWENDUNGEN IM LAND BERLIN

Transkript

1 LÖSUNGEN UND HANDLUNGSEMPFEHLUNGEN FÜR ARCHITEKTURKONZEPTE UND MIDDLEWARE FÜR E-GOVERNMENT-ANWENDUNGEN IM LAND BERLIN Abschlussbericht im Rahmen der Arbeitsgruppe middleware Mitglieder der Arbeitsgruppe: Senatsverwaltung für Inneres und Sport (Leitung), Senatsverwaltung für Wirtschaft, Forschung und Technologie (zeitweise), ITDZ, Fraunhofer FOKUS, Atos IT Solutions and Services GmbH Bericht erarbeitet von: Dr. Klaus-Peter Eckert, Lutz Nentwig, Rainer Rosenmüller Fraunhofer FOKUS Version Februar2015 Fraunhofer FOKUS, Kompetenzzentrum ELAN - 1 -

2 Fraunhofer FOKUS, Kompetenzzentrum ELAN - 2 -

3 Inhaltsverzeichnis 1 Einleitung Vorgehen Kriterien Untersuchung bestehender Lösungen Studie Berlin goberlin EU-DLR Bewertung und Blaupause Konsolidierung der verschiedenen Lösungen Bürgerportale, EA-Portal, goberlin Portale Workflow Bürgerkonto Fachverfahren und Fachdienste Dienste Diensteverwaltung Authentisierung (Sicherheitskonzept) IT-Infrastrukturdienste Beispiel Service-Konto Zusammengefasste Architektur Handlungsempfehlungen Abkürzungsverzeichnis Quellenverzeichnis Anhang: Grobarchitektur EU-DLR Anhang: Architektur goberlin Fraunhofer FOKUS, Kompetenzzentrum ELAN - 3 -

4 Abbildungsverzeichnis Abbildung 1: Funktionale Blöcke Berlin Abbildung 2 : Referenzmodell Studie Berlin Abbildung 3: Funktionale Blöcke von goberlin Abbildung 4 : Architekturkomponenten von goberlin Abbildung 5: Funktionale Blöcke der EU-DLR Abbildung 6: Grobarchitektur der EU-DLR des Landes Berlin Abbildung 7: Blaupause einer Berliner E-Government-Plattform Abbildung 8: Vorschlag der Realisierung Service-Konto Abbildung 9: Architektur Zusammenführung Abbildung 10: Grobarchitektur EU-DLR Abbildung 11: Deployment der funktionalen Komponenten von goberlin Abbildung 12: Anbindung der Authentisierungskomponenten in goberlin Abbildung 13: goberlin Authentisierung (Implementationskomponenten und ausgetauschte Artefakte) Fraunhofer FOKUS, Kompetenzzentrum ELAN - 4 -

5 1 EINLEITUNG Auf dem Entscheidertreffen des Projekts goberlin am 24. März 2014 wurde die Einrichtung einer strategischen Arbeitsgruppe unter der Federführung der Senatsverwaltung für Inneres und Sport vereinbar. Sie hatte den Auftrag, einen Vorschlag für eine landesweite Festlegung zur einzusetzenden Middleware zu erarbeiten und die notwendige Verbindlichkeit für den berlinweiten Einsatz herzustellen. Dadurch soll eine weitere weil unwirtschaftliche Diversifizierung der Zwischenanwendungen vermieden werden. Absehbare landesweite Projekte wie z. B. die E-Akte oder das Behördenportal erfordern ebenfalls diese Festlegung. Die Erarbeitung erfolgte auftragsgemäß unter Beteiligung der goberlin-konsortialpartner ITDZ, Fraunhofer FOKUS und Atos und weiterer Senatsverwaltungen. Ausgehend von den in den Projekten EU-DLR und goberlin sowie der Studie Berlin 100+ entwickelten Grobarchitekturen wurde in der Arbeitsgruppe ein erster Ansatz für eine zukünftige IKT-Architektur des Landes Berlin erarbeitet. Diese Architektur beschreibt auf hohem Abstraktionsniveau die funktionalen Komponenten der betrachteten Ansätze. Sie zeigt auf, wie und wo sich die vorhandenen Ansätze ergänzen, widersprechen oder gleichen. Die Inhalte der Arbeitsgruppe gingen über die Betrachtung einer Middleware-Lösung für das Land Berlin hinaus, da es der Gruppe wichtig erschien, auch die zu integrierenden Basisdienste und komponenten einer egovernment-plattform zu untersuchen. Ein Ergebnis der Arbeitsgruppe ist daher auch eine Blaupause für eine Architektur des Landes Berlin, die neben einer Middleware auch Basisdienste enthält. Neben der Bewertung der drei Ansätze und der Ableitung einer Blaupause in Kapitel 3 und 4 werden im Kapitel 5 Vorschläge für eine Konsolidierung, d.h. die Reduzierung mehrfach realisierten Funktionalitäten gemacht. Dieses Kapitel enthält auch beispielhaft einen Vorschlag, wie im Rahmen des 100+-Programms eine Komponente Service-Konto unter Wiederverwendung bestehender Komponenten und Plattformlösungen realisiert werden könnte. Danach wird aus der Blaupause und dem Vorschlag der Realisierung des Service- Kontos einschließlich der Berücksichtigung der Konsolidierungsvorschläge ein Architekturvorschlag für das Land Berlin abgeleitet. In dem Zusammenhang werden auch die erarbeiteten empfohlenen Basisdienste und allgemeine Anforderungen aufgeführt. Das Kapitel 6 enthält dann die Handlungsempfehlungen für ein weiteres Vorgehen. Fraunhofer FOKUS, Kompetenzzentrum ELAN - 5 -

6 2 VORGEHEN Ausgangspunkt der Untersuchungen war die Evaluation von im Land Berlin eingesetzten Middleware-Lösungen. Sämtliche Middleware-Produkte des Landes zu erfassen, wäre ein enormer und im geplanten Rahmen nicht zu bewältigender Aufwand. Darum wurden nur die drei erwähnten Projekte und damit die wichtigsten Middleware-Lösungen betrachtet. Schwerpunkt der Untersuchungen waren die Projekte EU-DLR, das Referenzmodell der Studie Berlin 100+ und das Projekt goberlin. Gemeinsamkeiten und Unterschiede wurden näher untersucht. In vier Arbeitstreffen wurde versucht, den Auftrag konkreter zu fassen als auch einen Einblick in die bestehenden IT-Lösungen zu bekommen. Dazu wurden möglichst die zuständigen und aussagefähigen Mitarbeiter der Projekte eingeladen und angehört. In der Regel wurden die vorbereiteten Beiträge durch eine intensive Frage- bzw. Diskussionsrunde ergänzt. Ziel war es Funktionalitäten und zugehörige IT-Komponenten für die Nachnutzung und Wiederverwendbarkeit zu extrahieren. Man unterscheidet zwischen Anwendungsorientierte Middleware, Kommunikationsorientierte Middleware und Nachrichtenorientierte Middleware. Allgemein kann man sagen Middleware 1 ist alles, das Funktionalität über der Betriebssystemschicht für die Anwendungen bereitstellt, die Komplexität aber vor diesen verbirgt. In dem Sinne kann man auch Basisdienste als Basisdienstorientierte Middleware betrachten und den ursprünglichen Auftrag erweitern. Gegenstand der Betrachtungen der AG Middleware sollten nicht nur die klassische Middleware, sondern auch die Basisfunktionalität einer E-Government-Plattform und der ihr zu Grunde liegenden Middleware einschließlich bestimmte Vorgehensmuster und die dazugehörigen Standardkomponenten, wie sie in den obigen Projekten zu sehen sind, sein. Nach den Vorstellungen und Vergleichen wurde aus dem Kreis des Projekts EU-DLR und der aktuellen Konzeption des Service-Kontos ein Vorschlag unterbreitet, wie man das Service-Konto mit bestehenden Komponenten realisieren könnte. 2.1 KRITERIEN Um die verschiedenen Ansätze miteinander vergleichen zu können, wird von einer Bewertung der Architekturen ausgegangen, die die nachfolgenden, u.a. aus dem SAGA-Standard abgeleiteten, Kriterien umfasst: 1. SOA wird als Architektur-Konzept verwendet. 2. Fachverfahren und unterstützende Basisdienste sind mit standardisierten Notationen wie WSDL beschrieben und bereitgestellt. 3. Die Sicherheitsarchitektur (hier Identifizierung und Vertrauensdienste) folgt dem Konzept der WS*- Standards, gekennzeichnet durch die Komponenten PEP, PDP, PAP, PIP und Verwendung der Standards SAML und XACML. Sie sollte weitestgehend unabhängig von der fachlichen Architektur beschrieben und in unterschiedlichen Kontexten wiederverwendbar sein. 1 Middleware stellt eine Ebene in einem komplexen Softwaresystem dar, die als Dienstleister anderen ansonsten entkoppelten Softwarekomponenten den Datenaustausch ermöglicht. Meist erfolgt diese Kommunikation mit Hilfe eines Netzwerkes, das durch die Middleware für die sie benutzenden Softwarekomponenten transparent gemacht wird. Middleware arbeitet dabei auf einem hohen Niveau innerhalb des Schichtenmodells: Ihre Aufgabe ist also nicht die Low-Level-Kommunikation für einzelne Bytes (wie sie beispielsweise schon ein Betriebssystem bereitstellt). Middleware organisiert den Transport komplexer Daten (sog. messaging), vermittelt Funktionsaufrufe zwischen den Komponenten (sog. Remote Procedure Calls), stellt die Transaktionssicherheit über ansonsten unabhängige Teilsysteme her (Funktion als Transaktions-Monitor) etc.: Wikipedia vom Fraunhofer FOKUS, Kompetenzzentrum ELAN - 6 -

7 4. Vorhandene Unterstützungsdienste werden wiederverwendet 5. Sofern möglich werden offene Standards eingesetzt. 6. Ein wirtschaftlicher Betrieb muss gewährleistet sein (Anschaffungskosten, Folgekosten, Wartbarkeit, Zuverlässigkeit) Fraunhofer FOKUS, Kompetenzzentrum ELAN - 7 -

8 3 UNTERSUCHUNG BESTEHENDER LÖSUNGEN Einerseits sind verschiedene parallel betriebene Systeme mit gleichen oder ähnlichen Funktionen unwirtschaftlich. Andererseits muss man in gewissem Maße Vielfalt zulassen, um Entwicklung zu ermöglichen und sich neuen Techniken und Anforderungen zu stellen. In diesem Abschnitt werden die betrachteten Systeme kurz vorgestellt und bewertet. 3.1 STUDIE BERLIN 100+ Die funktionalen Blöcke des Referenzmodells der Studie sind in Abbildung 1 dargestellt, das Referenzmodell selber ist in Abbildung 2 zu finden. Da es derzeit noch keine Umsetzung des Referenzmodells gibt, können keine weitergehenden technischen Aussagen gemacht werden. Es ist jedoch erkennbar, dass eine Umsetzung SOA orientiert ist, Fachdienste über zugehörige Konnektoren anbindet, von vorhandenen Unterstützungsdiensten Gebrauch macht, Sicherheitsdienste von den funktionalen Komponenten getrennt betrachtet und somit die Wiederverwendung existierender Lösungen ermöglicht. uc HundertPlusKomponenten Portal Fachv erfahren Unterstützungsprozesse Permanentes Bürgerkonto Identifizierung Backend-Komponenten Fachv erfahren-konnektor AAA-Dienste Kerndienste Unterstützungsdienste ABBILDUNG 1: FUNKTIONALE BLÖCKE BERLIN 100+ Fraunhofer FOKUS, Kompetenzzentrum ELAN - 8 -

9 Abbildung 2 : Referenzmodell Studie Berlin 100+ Fraunhofer FOKUS, Kompetenzzentrum ELAN - 9 -

10 3.2 GOBERLIN Die Grobarchitektur von goberlin ist in Abbildung 3 dargestellt und kann auf dieser Abstraktionseben gut mit Abbildung 1 verglichen werden. Eine mit dem Referenzmodell vergleichbare Darstellung ist in Abbildung 4 zu sehen. cmp Überblick goberlin-marktplatz goberlin-app-nutzermarktplatz goberlin-anbietermarktplatz «portal» Lebenslagenportal «portal» App-Entwicklerportal «portal» Fachdienstanbieterportal App-Laufzeitumgebung App-Entwicklungsinfrastruktur Marktplatzdienste Prozessdienste Plattformdienste Basisdienste «portal» Marktplatzbetreiberportal goberlin Marktplatz-Middleware Sicherheitskomponenten Cloud Infrastruktur und Dienste «portal» Betreiberportal Cloud-Infrastruktur ABBILDUNG 3: FUNKTIONALE BLÖCKE VON GOBERLIN Ergänzend zu den oben dargestellten funktionalen Blöcken von goberlin existieren detailliertere Architekturdarstellungen, aus denen insbesondere die Bereitstellung der Komponenten in der Oracle- Middleware und die Kopplung mit Oracle Sicherheitskomponenten dargestellt sind. Die zugehörigen Darstellungen sind im Kapitel 10 (Anhang) zusammengestellt. Es können folgende Aussagen zur Architektur gemacht werden: Die Architektur folgt dem SOA Konzept. Marktplatzdienste, Prozessdienste und Fachdienste werden als Webservice über zugehörige ESB-Instanzen angebunden (siehe Abbildung 11) Die Apps werden als Web-Anwendungen über einen sogenannten Pagelet-Producer an das Lebenslagenportal angebunden. Die Anbindung der Sicherheitskomponenten zur Authentisierung ist in Abbildung 12 dargestellt. Die Anbindung der Sicherheitskomponenten zur Autorisierung erfolgt über Interzeptoren in den zugehörigen ESB-Instanzen. Die Umsetzung Policy-gesteuerter Überprüfungen wurde exemplarisch nachgewiesen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

11 Die Portale sind mittels des vom Land Berlin in seinen Styleguides empfohlenen Framework Bootstrap entwickelt. Die Integrierbarkeit des Portals in vorhandene Portale hängt von den dort verwendeten Portaltechnologien und Sicherheitstechnologien ab. Fach-/ und Basisdienste werden in goberlin über einen logischen ESB angebunden. Neue Dienste können über diesen Mechanismus zur Verfügung gestellt und bei der Entwicklung neuer Anwendungen (Apps) einbezogen werden. Administrative Abläufe/Prozesse können über vorhandene, erweiterte oder neue BPMN-Prozesse als Prozessdienste umgesetzt werden. Prozessdienste sind aktuell mittels der standardisierten Notation BPMN spezifiziert und als Web-Service implementiert. Sie sind daher wie jeder andere Web-Service wiederverwendbar. Arbeitsanweisungen für Administratoren sind als sogenannte Human Tasks realisiert. Da diese ebenfalls über Web-Services implementiert sind ist es sowohl möglich, die Human Tasks aus anderen Umgebungen aufzurufen als auch alternative Vorgangsbearbeitungssysteme anzuschließen. Abbildung 4 : Architekturkomponenten von goberlin Fraunhofer FOKUS, Kompetenzzentrum ELAN

12 3.3 EU-DLR Jede Implementierung der EU-Dienstleistungsrichtlinie orientiert sich an den Vorgaben, die aus der EU- Richtlinie 2006/123/EG abgeleitet werden können. Ein Überblick über die funktionalen Blöcke der EU-DLR wird in Abbildung 5 gezeigt. deployment Hierarchie «execution environment» DL Umgebung «IMS» «execution environment» SOA Umgebung Basisdienste «execution environment» SOA Umgebung des EA «execution environment» SOA Umgebung VZF «execution environment» Wissensmanagement «execution environment» Zuständige Behörde - Fachverfahren «execution environment» Generalprozesse ABBILDUNG 5: FUNKTIONALE BLÖCKE DER EU-DLR Die funktionale Architektur der EU-DLR-Implementierung im Land Berlin weist spezielle Ausprägungen dieser funktionalen Blöcke auf, wobei nach Aussage des Verfahrensverantwortlichen einige Komponenten nicht umgesetzt worden sind. Abbildung 6 zeigt weiterhin, dass zur Implementierung der EU-DLR spezifischen Komponenten bereits vorhandene Komponenten um spezifische Komponenten ergänzt worden sind. Im Unterschied zur Abbildung 6 wurde nach Aussage des Verfahrensverantwortlichens in der letzten Überarbeitung der produktiven Instanz auf einige Komponenten verzichtet. Dass betrifft hauptsächlich den Interface Manager (EAI) und nach Aussage des ITDZ auch den Enterprise Service Bus (ESB). Die in der Abbildung dargestellte Architektur ist also nicht mehr die aktuelle realisierte Architektur. Das IT-Fachverfahren Gewerbe wurde auf jeden Fall dem Kunden- / Fallmanagement (KFM) direkt als Webservice zur Verfügung gestellt. Die Komponente Kunden / Fallmanagement (KFM) realisiert die Businesslogik mit Hilfe eines Formularservice cit intelliform der cit GmbH. Eine Quasi-semantische Prozess-Modellierung ist über SemTalk realisiert. SemTalk ist ein leistungsfähiges Werkzeug zur Prozessmodellierung und-analyse, das in der EU-DLR nicht vollständig genutzt wird. Zur Modellierung wird eine angepasste cit Edition genutzt. Die PKI wird mit Governikus umgesetzt. Das Protokoll (GUI) zwischen den Portal-Komponenten im oberen Teil der wurde durch das Protokoll WSRP (Web Services for Remote Portles) ersetzt. Alle Komponenten oder Dienste außer dem ESB und dem EAI im unteren Teil der Abbildung kann man als Basiskomponenten oder Basisdienste bezeichnen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

13 ABBILDUNG 6: GROBARCHITEKTUR DER EU-DLR DES LANDES BERLIN In den gemeinsamen Fachgesprächen zwischen dem Verfahrensverantwortlichen der Senatsverwaltung für Wirtschaft, Technologie und Forschung, dem ITDZ und Fraunhofer FOKUS wurden folgende Erkenntnisse gewonnen: Die Architektur folgt dem SOA Konzept Die Fachverfahren (u.a. FV Gewerbe) werden als Webservice angebunden. Das Kunden- und Fallmanagement ist über WSRP (Web Services for Remote Portles) am Portal angebunden und bildet mit diesem eine eigene Anwendung ( Fachverfahren ), über die Bürger (Dienstleister) die Funktionalität des Einheitlichen Ansprechpartners (EA) nutzen können. Wie die Basisdienste (Komponenten und Dienste und FV im unteren Block in Abbildung 6) angeschlossen sind, ist noch im Detail zu klären (möglicherweise sind diese über einen ESB angebunden). Zu einer möglichen Wiederverwendung der spezifischen Komponenten und dem Aufwand zur Anpassung (Schnittstellen, Sicherheit) kann keine Aussage gemacht werden. PKI, IDM, Verzeichnisdienst (basiert auf LDAP, verbunden mit dem Landes LDAP), sind sicher allgemeingültige Komponenten (der Sicherheitsarchitektur) Zur Absicherung der Aufrufe der Dienste gibt es keine Aussage. Wie weit die Sicherheitsarchitektur der Bedingung 3 genügt, ist nicht bekannt. Als PKI wird zumindest auf eine vorhandene Komponente (Governikus) zurückgegriffen. Zur Integrierbarkeit des Portals in andere Portale kann keine Aussage gemacht werden. Die Erweiterung oder Veränderung wird über die semantische Modellierung der Formulare (Datenmodell) und der Workflows (Prozesse) sowie über die Bereitstellung und den Anschluss neuer Dienste ermöglicht. Fraunhofer FOKUS, Kompetenzzentrum ELAN

14 4 BEWERTUNG UND BLAUPAUSE Die Auswertung der beschriebenen Architekturen und Ansätze führt zu folgendem Ergebnis: Die Architekturen widersprechen sich nicht und sind grundsätzlich vereinbar. Unterstützende Dienste sind grundsätzlich gegenseitig nutzbar. In welchem Umfang dies konkret technisch möglich ist, bedarf eingehender Untersuchungen. Prozessmodellierungen werden mit unterschiedlichen Mechanismen durchgeführt. Kundenmanagement und Fallmanagement sollten auf andere Verfahren übertragbar sein. Inwieweit die Prozessmodellierung für die EU-DLR auf andere Prozesse übertragen werden kann, ist detailliert zu untersuchen. Die Prozessmodellierung in goberlin nutzt offene Standards, die Vorgangsbearbeitung benutzt Oraclespezifische Komponenten ( Human Tasks ). Die goberlin-portale verwenden die in den Styleguides für das Land Berlin empfohlene Technologie. Das DLR-Portal ist bereits in integriert, verwendet jedoch eine eigene Nutzerverwaltung. Wie weit die Sicherheitsarchitektur der EU-DLR den Anforderungen entspricht, ist detailliert zu prüfen. Die Sicherheitsarchitektur von goberlin erfüllt nach den durchgeführten technischen Machbarkeitsnachweisen die gestellten Anforderungen. Wie weit der Service-Bus der EU-DLR den Anforderungen entspricht, ist noch einmal zu prüfen. Die Komponente ESB existiert so nicht. Nach Aussagen des Verfahrensverantwortlichens scheidet die Komponente Interface Manager (EAI) zur Nachnutzung aus, wegen der Abhängigkeit von T-Systems und der daraus folgenden Implementierungsaufwände und der reduzierten Flexibilität. Der Service Bus von goberlin erfüllt nach den durchgeführten technischen Machbarkeitsnachweisen die gestellten Anforderungen. In Abbildung 7 sind die funktionalen Komponenten einer E-Government-Plattform für das Land Berlin dargestellt, die sich aus einer Analyse der drei Architekturkonzepte ergeben. Die Komponenten sind dabei entsprechend ihrer Herkunft farblich gekennzeichnet. Grüne Komponenten sind allgemeine Bestandteile einer derartigen Plattform. Sie sind unabhängig von den betrachteten Architekturen vorhanden und können wiederverwendet werden, oder sie sind in einer der Architekturen identifiziert worden, von ihrer Natur aus aber mehrfach verwendbar. Rote Komponenten sind im Kontext von goberlin entwickelt worden, blaue im Kontext der EU-DLR und lila Komponenten sind für die Umsetzung der Studie Berlin 100+ erforderlich. Ein hoher Harmonisierungsbedarf besteht bei der Anbindung von Fachverfahren. Hier ist zu erkennen, dass diese Aufgabe in jedem der drei betrachteten Projekte vorhanden ist. Da es diesbezüglich noch kein etabliertes, universell einsetzbares Verfahren gibt, ist der Handlungsbedarf hoch. Fraunhofer FOKUS, Kompetenzzentrum ELAN

15 ABBILDUNG 7: BLAUPAUSE EINER BERLINER E-GOVERNMENT-PLATTFORM Die Integration der Portale erscheint technisch machbar zu sein. Interessant ist dabei die Harmonisierung der verwendeten Mechanismen zur Identifikation und Authentisierung. Im Zusammenhang mit Identifikation und Authentisierung ist auch eine Harmonisierung der Autorisierung und Abrechnung anzustreben. Unterstützende Basisdienste werden in allen Ansätzen benötigt. Dabei ist es wichtig, vorhandene Basisdienste über wohldefinierte Konzepte verfügbar zu machen und neue Basisdienste entsprechend zu gestalten. Verzeichnisdienste und Wissensmanagement sind universell verwendbar zu gestalten. Hier unterscheidet sich goberlin von den anderen Ansätzen. Während in goberlin Fachdienstanbieter (Verwaltungen) ihre Dienstleistungen explizit der Plattform verfügbar machen, sucht der Bürger in den anderen Projekten nach zuständigen Verwaltungen und deren Dienstangeboten. Das Zusammenschalten verschiedener Dienstangebote zu umfassenden Prozessen ist eine Aufgabe, die in unterschiedlichen Ausprägungen in allen Projekten vorhanden ist. In welchen Umfang hier eine Harmonisierung sinnvoll ist, muss gezielt untersucht werden. Dazu gehört auch die Berücksichtigung administrativer Vorgänge. Zum Service-Bus ist folgendes zu bemerken: Der Bus ist eher als gemeinsame Komponente zu betrachten (grün). Die Nutzung eines statischen Busses wird als nicht zielführend betrachtet. Er ist keine Lösung für Alles. Der Bus ist als logische Komponente zu betrachten und kann sich in einer Implementierung aus mehreren föderierten Produkten zusammensetzen. Er stellt eine allgemeine Komponente dar. Der wichtigste Bestandteil des Busses ist das Dienstverzeichnis, das für jede flexible wartbare Lösung benötigt wird. Fraunhofer FOKUS, Kompetenzzentrum ELAN

16 5 KONSOLIDIERUNG DER VERSCHIEDENEN LÖSUNGEN Die bzgl. der Blaupause (Abbildung 7) zu konsolidieren Aspekte werden in den folgenden Abschnitten untersucht. 5.1 BÜRGERPORTALE, EA-PORTAL, GOBERLIN PORTALE Die drei Portale Bürgerportal ( EU-DLR Portal und goberlin Marktplatzportal (App- Portal) haben ähnliche Funktionalität, nämlich Dienste oder Anwendungen zu suchen und aufzurufen (auszuführen). Da das EU-DLR Portal bereits im Bürgerportal enthalten ist und das goberlin Marktplatzportal nach den gleichen Standards und Styleguides entwickelt wurde, besteht hier kaum ein Konsolidierungsbedarf. Zu empfehlen ist hier eine Vereinheitlichung der Registrierung und des Identitätsmanagement und der Authentisierung im Zusammenhang mit der Entwicklung und Einführung des Service-Kontos. Wichtig ist alle zukünftigen Portale mittels des vom Land Berlin vorgegebenen Styleguides insbesondere des empfohlenen Framework Bootstrap zu entwickelt und das Protokoll WSRP (Web Services for Remote Portles) zu verwenden. Ziel muss die Möglichkeit der Integration in das Bürgerportal sein. 5.2 WORKFLOW Für die Realisierung des Workflows gibt es im Rahmen der Untersuchung drei Varianten der Orchestrierung von Diensten. 1. Ein in Java programmierter Workflow (Lebenslagen-App) zusammen mit der zugehörigen PaaS Entwicklerund Laufzeitplattform in goberlin 2. Das Fallmanagement+Kunden-/Fall-Prozessmanagement, der EU-DLR, das einen Formularservice mit deklarativen Prozessbeschreibungen und deren Interpretation verbindet (cit-tools und Laufzeitumgebung bzw. Compiler). 3. Das BPM Vorgangs-/Prozessmanagement aus goberlin mit deklarativen Prozessbeschreibungen (BPMN) und deren Interpretation verbindet (Oracle Tools und Laufzeitumgebung bzw. Compiler) Erwähnt werden muss in dem Zusammenhang, dass in Berlin zur Zeit zwei Formularservices, je ein Produkt der Firmen cit GmbH und BOL, im Einsatz sind. Zu empfehlen ist hier: 1. Die Beibehaltung der imperativen als auch der deklarativen Orchestrierung der Dienste. 2. Die Reduktion der Varianten der deklarativen Möglichkeiten. Dabei ist zu beachten: a. Die Oracle Variante hat sich im Projektverlauf als relativ komplex nutzbar erwiesen. Sie verwendet proprietäre, nicht standardkonforme Komponenten für die Einbindung und Darstellung der Human-Tasks. Sie besteht aus neuen Komponente, für deren Betrieb im ITDZ keine Erfahrung vorliegt. Im Fall der Abwahl dieser Variante müssen die im Projekt erzeugten BPMN-Prozesse mit einer anderen Engine ausgeführt werden, wobei eine Anpassung der Implementierung erforderlich wird. Die Human Tasks müssen von der proprietären Oracle-Lösung in eine standardisierte Lösung überführt werden. Dabei sollte an die Einbeziehung von im ITDZ bereits vorhandenen Vorgangsbearbeitungssystemen gedacht werden. Änderungen an den Klienten der Prozessimplementierung sind nicht zu erwarten. b. Die Lösung von cit hat sich in der EU-DLR bewährt und wird von den Betreibern als gut anwendbar und wartbar bezeichnet. Die Prozess-Komponente ist allerdings nicht auf dem neuesten Stand und darum im Augenblick noch nicht mit der vollen denkbaren Funktionalität nutzbar. Eine Modernisierung und Anpassung an Prozessstandards im Rahmen der Entwicklung des Service- Kontos wäre wünschenswert. Fraunhofer FOKUS, Kompetenzzentrum ELAN

17 5.3 BÜRGERKONTO Mit dem Begriff Bürgerkonto werden verschiedenen Funktionen verstanden, zusätzlich wird unterschieden, ob diese temporär oder permanent angeboten werden: 1. Zugangsdaten (Credentials) eines Kontos/Accounts zu verwalten (Name, Username, Password, Zertifikate) 2. Validierung der Daten 3. Verwaltung persönlicher Daten (Stammdaten) des Nutzers 4. Verwaltung der Eingangs- oder Ausgangsdokumente (z.b. Antrag, Bescheid) für oder von der Verwaltung von oder für den Nutzer (EU-DLR maximal 180 Tage) 5. Ausstellung von Identitätstoken (STS) 6. Verwaltung persönliche Dokumente des Nutzers (Datensafe) 7. Verwaltung persönliche s, d.h. auch ver/entschlüsseln, signieren, prüfen von Signaturen, senden und empfangen von s (Postfach) In der folgenden Tabelle werden die Eigenschaften der Konten der verschiedenen Lösungen verglichen. Die Funktionen 5 und 6 sollen hier nicht weiter betrachtet werden. Diese sind unter anderem in der Komponente Governikus realisiert. Funktion EU-DLR goberlin 1. Zugangsdaten ja Ja 2. Validierung Einfach, Rückmail Bürger nein; Anbieter ja 3. Stammdaten Ja Ja 4. Dokumentenablage Ja für maximal 180 Tage Nein 5. STS unbekannt Ja, aber siehe Beispieldiskussion Siehe auch Beispieldiskussion Abschnitt FACHVERFAHREN UND FACHDIENSTE Aus den bestehenden Fachverfahren sollten die von anderen Verfahren oder vom eigenen zu modernisierenden Verfahren wiederverwendbaren Funktionalitäten als Dienste (Webservices) herausgelöst und bereitgestellt werden. Das kann aus wirtschaftlichen Gründen aber nur sehr langfristig im Einzelfall und im Rahmen weiterer Modernisierungen oder Neuentwicklungen geschehen. Neue oder modernisierte Fachverfahren können dann unter Nutzung von diversen Fachdiensten, Basisdiensten und Infrastrukturdienste (z.b. Workflow siehe oben) relativ flexibel erstellt oder erweitert werden, zum Beispiel zur Entwicklung von Online Transaktionen. 5.5 DIENSTE Marktplatzdienste aus goberlin kapseln weitestgehend die für goberlin verwendeten Daten. Sie sind in Teilen auch außerhalb von goberlin nachnutzbar, sofern eine Konsolidierung der Datenstrukturen durchgeführt wird.. Wenn ganze Infrastrukturkomponenten/Dienste aus goberlin für die E-Government-Plattform bereitgestellt werden sollen, wie im Beispiel (siehe unten) so ist dieses Vorgehen sinnvoll. Die im Projekt goberlin genutzten Basisdienste wie ZMS sind nach im Projekt festgelegten Konformitätsregeln angesprochen worden und können überall wiederverwendet werden. Für das Bereitstellen von allgemeinen Diensten wird empfohlen, ebenfalls diese Konformitätsregeln einzuhalten. Wenn diese Konformitätsregeln nicht eingehalten werden (können), das betrifft fast alle alten bestehenden Dienst aber möglicherweise auch neu zu entwickelnde, so wird die erweiterte Funktionalität eines ESB (Service Bus) benötigt. Dann wird die Möglichkeit, Datenmodelle, Schnittstellen und Protokolle anzupassen und Fraunhofer FOKUS, Kompetenzzentrum ELAN

18 entsprechende Proxy-Dienste anzubieten, erforderlich. Das gilt besonders, wenn verschiedene Fachverfahren die gleichen Fachdienste nutzen, aber kein einheitliches Datenmodell möglich oder zeitnah realisierbar ist. 5.6 DIENSTEVERWALTUNG Es gibt zwei Funktionen, die eine Diensteverwaltung erfüllen kann: 1. Veröffentlichung der bereitgestellten Dienste, ihre Funktionalität und andere Metadaten, die dem Nutzer ermöglichen den richtigen Dienst zu finden. 2. Veröffentlichung der technischen Adressen der Dienste, um diese aufrufen zu können. Punkt 1 wird in unterschiedlichen Kontexten und Ausführungen dreimal bereitgestellt (siehe Abschnitt 5.1). Es gibt aber auch zwei Nutzergruppen, die unterschiedlichen Informationsbedarf haben. Das ist einmal der Bürger, der eine für ihn bestimmte Anwendung oder Dienst sucht um ihn zu nutzen und das ist andererseits der Entwickler, der einen Dienst sucht, der eine Funktionalität anbietet, die er in seine Anwendung einbinden möchte. Dem Bürger steht dafür das Bürgerportal ( zur Verfügung. Für die Entwicklung neuer Anwendungen notwendigen Informationen werden im Bürgerportal ( nur rudimentär angeboten. Im goberlin Entwicklerportal ist dagegen ein entsprechendes Diensteverzeichnis vorhanden. In ihm müssen alle Basis- und Fachdienste, die für die Allgemeinheit zur Entwicklung bereitgestellt werden, beschrieben werden. Insbesondere müssen definiert werden die Funktion des Dienstes, unabhängig von der inneren Architektur, als auch die Schnittstellen (Syntax und Datenmodell, Semantik, Verhalten, d.h. Abfolge der Funktionsaufrufe, Aufrufprotokoll usw.). Hier ist zu empfehlen, das goberlin Portal zu nutzen, da dieses für diesen Umfang konzipiert wurde. Das Bürgerportal wäre auf Grund seiner primären Zielgruppe dafür weniger geeignet. Sinnvoll wäre es aber die Inhalte bei Überschneidungen abzustimmen und aus einer gemeinsamen Quelle bereitzustellen. Zum Punkt 2 ist zu sagen, dass er in goberlin (goberlin Diensteverwaltung) konzeptionell vorgesehen ist, aber die Implementation noch nicht vollständig ist. Wie dieser Punkt in der EU-DLR (EU-DLR Wissensmanagement und Verzeichnisse) umgesetzt ist, konnte im Rahmen der AG nicht geklärt werden. 5.7 AUTHENTISIERUNG (SICHERHEITSKONZEPT) Das Sicherheitskonzept in goberlin folgt dem Konzept der WS*-Standards, gekennzeichnet durch die Komponenten PEP, PDP, PAP, PIP und Verwendung der Standards SAML und XACML. Es beruht auf dem Austausch von X509 Token und SAML Assertions (siehe Abbildung 13). Die Realisierung der Authentisierung in der EU-DLR ist, konnte nicht geklärt werden. Im Konzept für das Service-Konto wird vorgeschlagen OAuth zu nutzen. Langfristig sollte man beide Varianten anbieten. Dabei ist zu beachten, dass man aus Sicherheitsgründen auf die aktuelle Version (OAuth 2.0) verwenden soll. 5.8 IT-INFRASTRUKTURDIENSTE Vorschläge für die Konsolidierung der Plattformdienste sind in den verschiedenen Absätzen gemacht worden, in denen sie eine Rolle spielen. Für Cloud-Dienste besteht kein Bedarf der Konsolidierung, da im ITDZ nur ein Cloud-Dienst (IaaS) angeboten wird und goberlin nur einen Dienst (PaaS), einschließlich Plattformdiensten, zur App-Entwicklung anbietet und nur eine Plattform für SaaS-Dienste, die Apps, anbietet. Die Verwendung der ITDZ-Cloud als technische Infrastruktur ist aus technischen und lizenzrechtlichen Gründen gesondert zu untersuchen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

19 5.9 BEISPIEL SERVICE-KONTO Nachfolgend wird ein im Rahmen der AG diskutiertes Beispiel für die Verwendung der Vorlage für die Realisierung eines Service-Kontos aus bestehenden Komponenten (Abbildung 8) dargestellt. Das Beispiel ist ein erster Vorschlag für die Realisierung eines Service-Kontos (Bürgerkonto) im Land Berlin. Das Service-Konto soll einer der zentralen Basisdienste für das Service-Portal und der E-Government-Infrastruktur des Landes Berlin werden. Der Entwurf einer Grobarchitektur verwendet folgende Komponenten wieder cit intelliform Server (EU-DLR im Land Berlin) Service-Konto-Application (Datenzentrale Baden Württemberg) Identity Management (IDM,STS) (aus der Sicherheitsarchitektur von goberlin in Verbindung mit Marktplatzdiensten bzgl. Nutzer und Konto) Beim Baustein Anwendung X (siehe Abbildung 8) handelt es sich in der Regel um Alt-Anwendungen. Über den Service Konto-Bar (Snippet) kann man sich in der Anwendung X mit seinem Service-Konto anmelden. Die Prüfung der Identität eines Nutzers für den Aufruf eines Fachdienstes erfolgt durch das IDM, die dazu aus goberlin herausgelöst werden müsste. 2 Folgende Punkte sind im Detail zu prüfen: Verfügbarkeit der einzelnen Lösungsbausteine, u.a. Produktreife, Lizenzbedingungen, Kooperation Datenzentrale Baden Württemberg (erstes Ergebnis siehe Abbildung 8) Nutzung des IDM (goberlin) durch die CIT-Dienste: u.a. Spezifikation der bereitgestellten IDM-Dienste, Status der Realisierung (siehe Abbildung 13) 2 Das könnte etwas mehr Aufwand erfordern, da zur Zeit einige Daten redundant (LDAP und SQL) gehalten werden. Die Realisierung der Redundanz erfolgt aus den Dialogen der Anwendung. Fraunhofer FOKUS, Kompetenzzentrum ELAN

20 ABBILDUNG 8: VORSCHLAG DER REALISIERUNG SERVICE-KONTO (Legende: Komponente im Land Berlin lizenziert, Komponente vorhanden aber noch nicht lizenziert, Zu ergänzende Komponente) In der Abbildung 13 ist kurz zusammengefasst, was in den Dokumentationen von goberlin zu der Sicherheitsarchitektur und ihrer Realisierung dargestellt ist. Die Darstellung zeigt die Absicherung eines Dienstes nach WS-Traust mit den notwendigen abstrakten Komponenten. Sie ist um einige Produktnamen bzw. Oracle Komponenten aus der Implementation ergänzt worden. Der OAM stellt das WS-Trust-Interface (STS) bereit. Das Sicherheitskonzept in der dargestellten Form wurde zwar getestet, wird zur Zeit im Prototypen aber nicht verwendet. Im LDAP stehen nur die Nutzerdaten, die für die SAML Assertion notwendig sind. Das Password steht nur im LDAP. Die anderen Daten können auch in der Oracle Datenbank der goberlin Nutzerverzeichnisse stehen. Die Redundanz der Daten wird bei der Registrierung der Nutzer für diesen versteckt durch zwei entsprechende Schreiboperationen aus dem Dialog heraus erzeugt. Weitere Nutzerdaten stehen möglicherweise nur in den Nutzerverzeichnissen von goberlin. Ein herauslösen des IDM(STS) ist somit problematisch. Zur Lösung wären mindestens die folgenden Punkte zu berücksichtigen: 1. Alle für das Service-Konto relevanten Daten sollten nur im OAM/LDAP gespeichert werden. 2. Für das Schreiben und Lesen dieser Daten, die von goberlin benötigt werden, dürfen dann nur noch die Schnittstellen des Service-Konto genutzt werden, d.h. das WS-Trust-Interface sollte auch vom Service- Konto angeboten werden und die goberlin Portale müssen auch das Konto-Bar-Snippet nutzen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

21 5.10 ZUSAMMENGEFASSTE ARCHITEKTUR Wenn man die Übersicht aus Abbildung 7 und Abbildung 8 zusammenführt, so erhält man eine vereinfachte Architektur wie in der Abbildung 9 zu sehen ist. Die Farbcodierung entspricht der aus Abbildung 7. Weiterhin ist zu bemerken, dass die Persistenzschicht (Datenbanken) in der Regel nicht mit betrachtet werden, sondern nur die darüber liegenden Verwaltungsdienste. Die Portale wurden in Abschnitt 5.1 beschrieben. Das Bürgerkonto wurde durch das Service-Konto als erste Realisierungsstufe ersetzt. Dieses soll bundesweit Gültigkeit haben, d.h. es sind Interoperabilitätsanforderungen zwischen den Lösungen zu spezifizieren und umzusetzen. Zielgruppe sind alle Kunden der Verwaltung einschließlich Ausländern (nicht die FV-Bearbeiter). Die zusätzlichen funktionalen Komponenten (Datensafe, Postfach) müssen parallel dazu hinzugefügt werden (siehe auch Abschnitt 5.3). Sie nutzen dann aber das Service-Konto für die Registrierung und Authentisierung. Mit dem Service-Konto ist hier die in Abbildung 8 als cit intelliform Server benannte Komponente gemeint. Das Identity-Management IDM (STS) mit dem LDAP ist herausgelöst als IDM (STS) und ID und Profildaten unten links zu finden. Die Fachdienste und Fachverfahren werden nach Anschnitt 5.5 und Abschnitt 5.4 bereits als vereinheitlicht angenommen. Der Konnektor ist optional aber in der Realität oft notwendig. Dieser ist aber im Fall der Verwendung eines ESB Bestandteil des Service Busses und eben dort angesiedelt. Die Marktplatzdienste von goberlin bleiben bestehen Sie sind im Rahmen ihrer fachlichen Semantik in anderen Kontexten wiederverwendbar. Wie weit einzelnen Anwendungen noch eine spezifische Nutzerverwaltung benötigen, hängt davon ab, wie umfangreich und flexibel das Service-Konto konzipiert wird, so dass alle Anwendungen ihre Nutzerinformationen über das Service-Konto managen können. Autorisierung und Abrechnung/Bezahldienst wurden getrennt. ABBILDUNG 9: ARCHITEKTUR ZUSAMMENFÜHRUNG Zu den BPMN und KFM Komponenten und den Lebenslagen Apps siehe auch 5.2. Eine Prozess-Engine als Laufzeitumgebung für Prozesse und Workflows, vergleichbar Application-Servern, stellt eine Laufzeitumgebung Fraunhofer FOKUS, Kompetenzzentrum ELAN

22 für ausführbare Prozesse dar und muss bereitgestellt werden. Dazu ist auch ein Vorgangsbearbeitungssysteme (z.b. Human Tasks) ergänzend bereitzustellen. Die Dienstverwaltungen werden auch langfristig in einem gewissen Umfang in zwei Ausführungen bestehen bleiben (siehe Abschnitt 5.6). Die Plattformdienste sind Bestandteil des PaaS Teils von goberlin und müssen, wenn dieser Dienst zukünftig angeboten werden soll, zusammen mit allen anderen Komponenten von goberlin bereitgestellt werden. Unter sonstige IT-Infrastrukturdienste sind alle weiteren potentiellen Basisdienste zu verstehen, die hier noch nicht genannt sind. Möglicherweise bietet es sich im Rahmen der Entwicklung des Service-Kontos an, weitere Komponenten aus dem cit intelliform Server zur Wiederverwendung als extra Dienst herauszulösen. Die Arbeitsgruppe hat folgende Empfehlungen für weitere wichtige Basisdienste erarbeitet: 1. Ein Postfach, das nicht zum Service-Konto gehört, soll als weiterer Basisdienst parallel bereitgestellt werden. 2. Ein wichtiger Basisdienst ist das Payment, insbesondere für eine angestrebte (notwendige) Änderung der Verfahren hin zur Vorkasse. 3. Ein Zuständigkeitsfinder ist notwendig. DVDV ist für eine umfängliche Information der Bürger nicht ausreichend. 4. Die Dienste aus der Liste, der in goberlin zusammengestellten, im ITDZ bereits vorhandenen Basisdienste, werden ebenfalls empfohlen. Der Dienst ZMS wurde bereits in goberlin verwendet. DMS/VBS - Dokumentenmanagement- und Vorgangbearbeitungssystem FMS - Formularmanagementsystem I FMS - Formularmanagementsystem II MD - Massendigitialisierung/eArchiv CMS - Contentmanagementsystem VPS - Virtuelle Poststelle ZMS - Zeitmanagementsystem OMS - Outputmanagementsystem UMS - Unified Messaging System DLDB - Dienstleistungsdatenbank eid-service RBS - regionales Bezugssystem und andere Datenbanken des AfS KVD - Konvertierungs- und Validierungsdienst, Hashwertdienst Die wesentlichste Komponente der Architektur ist der Service Bus. Er ist ein Konzept zur Schaffung von Interoperabilität in verteilten Systemen. Er ermöglicht eine flexible zukunftsfähige Anwendungslandschaft mit einem hohen Grad an Nachnutzung mehrfach verwendbarer Dienste. Er stellt eine zentrale Verwaltung für die technischen Aufrufadressen der Dienste bereit bzw. übernimmt das Routing. Unabhängig ob der Bus zentral oder verteilt realisiert wird, ist er der Ansprechpartner für die Vermittlung der Kommunikation zwischen den Anwendungen und den Diensten. Er ermöglicht die Transformation und das Mapping von Schnittstellen, Protokollen und Daten. Das ist besonders wichtig, wenn man Komponenten aus einer lange gewachsenen heterogenen IT-Landschaft mit einander verbinden will. Er ist der Punkt an dem ein einheitliches Logging und Monitoring der Arbeit der Dienste realisiert werden kann. Damit wird der Aufwand für die Wartung reduziert und mehr Zuverlässigkeit für das Gesamtsystem geschaffen. Er ist der Punkt, an dem die Sicherheitsaspekte berücksichtigt werden können und zur gemeinsamen Sicherheitsarchitektur verzweigt werden kann. Er implementiert die Sicherheitseinschränkungen zwischen unterschiedlichen Sicherheitsdomänen. Falls die Dienste die Transaktionsprotokolle unterstützen, können über den Bus übergreifende Transaktionen definiert werden. Er kann auch das Hosting und die Lastverteilung übernehmen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

23 Die folgenden Anforderungen sind in der E-Government-Plattform immer zu berücksichtigen: 1. Sicherheit a. Sicherheitsanforderungen (an die Architektur) müssen abgestuft gestaltet werden b. Föderiertes (auf verteilte Domänen verteiltes) Identity-Management ist wünschenswert c. Fachverfahren bringen derzeit zumeist ein eigenes Rechte- und Rollenmanagement mit, diese sollten weitgehend berücksichtigt/erhalten werden d. Das Identitätsmanagement (IDM) muss dagegen vereinheitlicht werden e. Statt dem Papierweg mit Unterschrift des Bürgers wird der elektronische Weg gefordert einschließlich der Nutzung von eid und QES. f. Alle Komponenten sollen zukünftig mit dem Service Konto als IDM/STS zusammenarbeiten. 2. Fachverfahren a. Der Bearbeitungsstand eines Fachverfahrens/-dienstes muss abgefragt werden können (T&T). b. Die Rückinformation der FV über erfolgte Zahlung ist unbedingt nötig. c. Schnittstellen müssen offen sein (nicht durch ein Produkt bestimmt). 3. Middleware a. Typische Bestandteile einer Middleware sind Portal-Server, Application-Server, Kommunikations- Software/-Busse, Datenbanken, diese sind langfristig durch die Reduktion der Produktvielfalt zu harmonisieren. b. Für Portale sind das Protokoll WSRP und weitere (Web-)Vorgaben des Landes Berlin zueinzusetzen bzw. zu beachten. Die Einbeziehung von Web-Anwendungen über leichtgewichtigere Protokolle ist ebenfalls zu unterstützen. 4. Allgemein a. Die Festlegung auf eine Programmiersprache wie Java wird als nicht sinnvoll angesehen. Vielmehr sollen programmiersprachenunabhängige Schnittstellen vorgegeben werden. Andererseits legt die Festlegung auf unterstützte Middleware-Produkte bereits bestimmte Programmiersprachen fest, wobei derzeit Java die größte Verbreitung besitzt. Fraunhofer FOKUS, Kompetenzzentrum ELAN

24 6 HANDLUNGSEMPFEHLUNGEN Das Land Berlin steht strategisch vor der Aufgabe, Fachverfahren elektronisch zu modernisieren, mit anderen Diensten zu kombinieren, beispielsweise die Integration der eakte, und möglichst viele IT-Fachverfahren auch als Online-Dienste dem Bürger und der Wirtschaft zugänglich zu machen. Daher empfehlen wir 1. den Aufbau eines Architekturmanagements (Portfoliomanagement), d.h. eine kontinuierliche ganzheitliche Betrachtung und Veränderung der IT-Architektur des Landes Berlin zu betreiben. Architekturmanagement (auch Enterprise Architecture Management (EAM), IT-Governance, IT- Management) ist ein Prozess nach einem Vorgehensmodell unter Nutzung eines Frameworks zur Kontrolle der bestehenden sowie zur Planung und Durchsetzung einer verbesserten IT-Unterstützung in einer großen Organisation. Dabei werden nicht eine oder wenige Anwendungsarchitekturen betrachtet, sondern die Gesamtheit der Architekturen der Organisation. Ziel ist deren Optimierung bezüglich der sich dynamisch verändernden Strategie der Organisation, der technischen Entwicklung und dem Lebenszyklus der eingesetzten Konzepte, Standards, Soft- und Hardware, die dazu einer Bewertung unterzogen werden. Zwei Vorgehensmodelle und Frameworks sind z.b. TOGAF [16] und die Softwarekartographie von Sebis TUM [17]. Sinnvoll wäre langfristig auch die Ableitung von Domän- oder General-Modellen für einzelne schwerpunktmäßige Aufgaben. 2. den Aufbau einer konsolidierten E-Government-Diensteplattform (siehe Abschnitt 5.10). Zur Konkretisierung der beiden Ziele empfehlen wir folgendes technische Vorgehen: - Einführung eines ESB als Service-Bus, um die zu erwartende Heterogenität der Dienste meistern zu können und wichtige zentrale Funktionen bereitzustellen (Anbindung der Sicherheitsarchitektur, Logging, Monitoring). - Bereitstellen eines Verzeichnisdienstes aller potentiell wiederverwendbaren Komponenten und Architekturmuster, d.h. der relevanten Information zu den Diensten (Funktionalität, Schnittstellen, Erreichbarkeit usw.) für alle Entscheidungsträger und Entwickler, um zukünftig eine Wiederverwendung zu erreichen. Hier ist die Verwendung des goberlin Marktplatz-Diensteverzeichnisses und die Nutzung der Dienstleistungsdatenbank zu empfehlen (siehe Abschnitt 5.6). - Festlegung auf ein Sicherheitskonzept bzw. eine Sicherheitsarchitektur im Zuge der Entwicklung des Service-Kontos. Die Konzepte von WS* mit XACML und SAML müssen umgesetzt werden. OAuth 2.0 kann auch angeboten werden. - Bereitstellung der zentralen Sicherheitsarchitektur nach WS*-Konzepten. Diese kann nach dem WS- Federation Standard auch verteilt über mehrere Sicherheitsdomänen realisiert werden. - Eine kontinuierliche Prüfung aller vorhandenen und neuen technischen Komponenten oder Fachverfahren / Dienste auf das Vorhandensein von Komponenten / Dienste mit mehrfach verwendbarer Funktionalität und deren Eignung für die Wiederverwendung (Anforderungen, Interoperabilität) in der Plattform (potentiell wiederverwendbaren Komponenten und Architekturmuster). Als Grundlage können die Dokumente goberlin Basistechnologien [10] und Programm 100+ [18] dienen - Gezielte Instanziierung von Komponenten / Diensten wenn aus aktuellen Projekten der Bedarf angemeldet wird. Das kann durch gezieltes Herauslösen aus bestehenden Lösungen, Neuentwicklung oder Kauf geschehen. Fraunhofer FOKUS, Kompetenzzentrum ELAN

25 Realisierung der Empfehlungen Wir empfehlen im Rahmen des Projekts Service Konto den Aufbau der Abschnitt 5.10 skizzierten konsolidierten IT-Architektur (Blaupause) inklusive einer landesweiten Middleware zu beginnen. Die Realisierung des Service-Kontos sollte unter Wiederverwendung der vorgeschlagenen Komponenten (siehe Abschnitt 5.9) erfolgen. Daraus folgt die Nachnutzung von Komponenten und Diensten aus der EU-DLR und goberlin: der Einsatz des Service-Bus (OSB) aus goberlin als Basis für die Integration von Diensten die Festlegung der Sicherheitsarchitektur auf die WS*-Standards (Authentisierung, Autorisierung) aus goberlin die Festlegung der Konformität, beschrieben in goberlin [9], für die Bereitstellung der Dienste die Festlegung auf das Diensteverzeichnis von goberlin für die Entwickler der Einsatz weiterer Oracle Werkzeuge aus goberlin der Einsatz des cit intelliform Server aus EU-DLR der Einsatz der Service-Konto-Application der Datenzentrale Baden Württemberg In diesem Rahmen ist auch noch einmal zu prüfen, ob für die Instanziierung der E-Government-Plattform der Einsatz von Open Source Middleware- und Sicherheitskomponenten, z.b. Komponenten der Jboss-Familie, wirtschaftlicher und flexibler ist als der Einsatz der in goberlin benutzten Oracle-Produkte. Fraunhofer FOKUS, Kompetenzzentrum ELAN

26 7 ABKÜRZUNGSVERZEICHNIS Abkürzung BSI CMS EAI ESB IaaS IDM ITDZ KFM MP NIST OAM OES OHS OID OIM OSB OSTS OUD OWLS OWSM PaaS PAP PDP PEP PIP QES SaaS SAGA SAML SCA STS URL WLS XACML Bedeutung Bundesamt für Sicherheit in der Informationstechnik Content-Management-System Enterprise Application Integration Enterprise Service Bus Infrastructure as a Service Identitätsmanagement (auch IdM, Identity Management) IT-Dienstleistungszentrum Berlin Kunden- und Fall-Management Marktplatz National Institute of Standards and Technology Oracle Access Manager Oracle Entitlements Server Oracle HTTP Server Oracle Internet Directory Oracle Identity Manager Oracle Enterprise Service Bus Oracle Security Token Service Oracle Unified Directory Oracle WebLogic Server Oracle Web Services Manager Platform as a Service Policy Administration Point Policy Decision Point Policy Enforcement Point Policy Information Point Qualifizierte Elektronische Signatur Software as a Service Eigenname, ursprünglich Abkürzung von Standards und Architekturen für E-Government-Anwendungen Security Assertion Markup Language Service Component Architecture Security Token Service Uniform Resource Locator WebLogic Server extensible Access Control Markup Language Fraunhofer FOKUS, Kompetenzzentrum ELAN

27 8 QUELLENVERZEICHNIS [1] goberlin, Ergebnisdokument E1.3 (V2.0), Anforderungsspezifikation und Grobarchitektur Lastenheft, Oktober.2014 [2] goberlin, Ergebnisdokument E2.1 (V1.0.1) Sicherheitskonzept: Rahmendokument, [3] goberlin, Ergebnisdokument E2.1 (V1.0) Sicherheitskonzept: Anlagen zum Rahmendokument, [4] goberlin, Ergebnisdokument E3.2 (V1.0) Anwendungsarchitektur, [5] goberlin, Der vertrauenswürdige Dienstemarktplatz in der Cloud Konzeptionelles Whitepaper, Mai 2013 [6] goberlin, Konzept für die Realisierung der Entwicklungsplattform, (V0.0.2), [7] goberlin, Ergebnisdokument E3.4 Anhang: Cloud-Konzept, (V 1.0), [8] goberlin, Ergebnisdokument E3.4 Rahmenarchitektur, (V 1.0), [9] goberlin, Ergebnisdokument E3.2 (V1.0) Anhang: Leitfaden für Fachdienstentwickler, [10] goberlin, Ergebnisdokument E3.1 Strategie zur Verwendung von Basistechnologien Version Final, [11] [12] aktuelle%20version/saga_5_aktuelle_version_node.html [13] IT-Standards der Berliner Verwaltung 2013, Senatsverwaltung für Inneres und Sport, [14] Udo Rienaß, Ralf Ganser, Umsetzung der EU-Dienstleistungsrichtlinie als Referenzarchitektur für egovernment-prozesse, 10. egovernment-wettbewerb für Bundes-, Landes- und Kommunalverwaltungen 2010, Kategorie 3 - Innovativstes egovernment- Architekturprojekt, Senatsverwaltung für Inneres und Sport, [15] RICHTLINIE 2006/123/EG DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 12. Dezember 2006 über Dienstleistungen im Binnenmarkt [16] [17] André Wittenburg, Softwarekartographie: Modelle und Methoden zur systematischen Visualisierung von Anwendungslandschaften, Institut für Informatik der Technischen Universität München, 2007 [18] PROGRAMM 100+, eid-strategie UND AUFBAU VON TRANSAKTIONSDIENSTEN FÜR DAS LAND BERLIN ( ), Senatsverwaltung für Inneres und Sport, November 2013, ISBN Fraunhofer FOKUS, Kompetenzzentrum ELAN

28 9 ANHANG: GROBARCHITEKTUR EU-DLR deployment Artifacts «executionenvironment» DL Umgebung Die Kommunikation zwischen EA Komponenten und den Nutzern wird über "mehrkanalfähige Dienstportale" realisiert und ist durch <<IMS>> gekennzeichnet. «portal» DL Proxy «service» Erweiterter Dokumentensafe EDS «IMS» Die technische Kommunikation zwischen den Komponenten des DLR Systems wird in einer mittels <<GSB>> gekennzeichneten Infrastruktur durchgeführt. Darunter wird ein verteilter Dienstbus verstanden, der in einer SOA Umgebung durch einen "Enterprise Service Bus" oder einen speziellen "Government Service Bus " GSB-Ansatz realisiert werden kann. «executionenvironment» SOA Umgebung des EA «portal» DLR Portal EA Verzeichnis «executionenvironment» SOA Umgebung Basisdienste «service» Authentisierungsprüfer AP «portal» Einheitlicher Ansprechpartner EA «service» Identitäts-Provider IP «service» Rechnungswesen EA «executable» Fachverfahren FV Adapter «executionenvironment» Zuständige Behörde - Fachverfahren «portal» ZB Zuständige Behörde «service» Rechnungswesen ZB «service» Virtuelle Poststelle VPS Fachverfahrenverzeichnis FVV «service» Formularserver Nationales Prozessverzeichnis FV NPV Deutsches Verwaltungsdienstverzeichnis DVDV «executionenvironment» SOA Umgebung VZF «service» Verzeichnisbasierter Zuständigkeitsfinder VZF «executionenvironment» Wissensmanagement VZF Leistungsverzeichnis Geschäftslagen-Verwaltungsleistungen Verzeichnis GVV VZF Einrichtungsverzeichnis Geschäftslagenverzeichnis VZF Gebietskörperschaftsverzeichnis Binnenmarktinformationssystem IMI VZF Zuständigkeitsverzeichnis VZF Weitere Verzeichnisse «executionenvironment» Generalprozesse Generalprozessverzeichnis GV «service» Metaformular Dienst MD EA übergreifendes GV Verzeichnis EGV ABBILDUNG 10: GROBARCHITEKTUR EU-DLR Fraunhofer FOKUS, Kompetenzzentrum ELAN

29 10 ANHANG: ARCHITEKTUR GOBERLIN Lebenslagen-Portal mit Registrierung und Anmeldung Oracle WebLogic Portal als Webanwendung Dienstassistent Oracle WebLogic App-Entwickler-Portal Fachdienstanbieter-Portal Portal als Webanwendung WS SOAP Http URL mit AppId UserId WS SOAP WS SOAP OSB1 OSB3 Oracle WebLogic Marktplatzdienste WS SOAP Oracle WebLogic BPM- Engine BPM-Prozesse REST Oracle WebLogic Plattformdienste WS SOAP Build-Umgebung für App-Entwickler Pagelet Producer Oracle WebLogic Apps als Webanwendungen OSB2 Oracle WebLogic BPM- Konsole Business Process Workspace mit Human Tasks IDE bei App-Entwickler WS SOAP OWLS mit Fachdienst- Wrapper Fachdienste ABBILDUNG 11: DEPLOYMENT DER FUNKTIONALEN KOMPONENTEN VON GOBERLIN Client OAM OHS Webgate LDAP Portale Pagelet Producer App OWSM Client OES PAP PIP OSB PEP/ PDP Service Proxy Interceptor Business Proxy MP- Dienste Prozessdienste Fachdienste ABBILDUNG 12: ANBINDUNG DER AUTHENTISIERUNGSKOMPONENTEN IN GOBERLIN Fraunhofer FOKUS, Kompetenzzentrum ELAN

30 ABBILDUNG 13: GOBERLIN AUTHENTISIERUNG (IMPLEMENTATIONSKOMPONENTEN UND AUSGETAUSCHTE ARTEFAKTE) Fraunhofer FOKUS, Kompetenzzentrum ELAN