Konzeption des BauVOGrid-Portals

Transkript

1 Grid-basierte Plattform für die Virtuelle Organisation im Bauwesen Gefördert durch Förderkennzeichen: 01IG07001 BauVOGrid-Bericht A-6.2 Konzeption des BauVOGrid-Portals Verantwortlicher Partner: Verfasser: SEIB ITC GmbH Peter Hornung, SEIB ITC GmbH Autor(en): Peter Hornung, Frank Hilbert, Peter Katranuschkov, Peter Öhring Datum : Version: 1.1 Verteiler: Projektpartner X Projektträger X D-Grid X Öffentlichkeit X Copyright: BauVOGrid-Konsortium Projektlaufzeit: 06/ /2010

2 Konsortium Institut für Bauinformatik der Technischen Universität Dresden Dresden Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik (FIRST) Berlin Institut für Wirtschaftsinformatik (IWi) im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) Saarbrücken Seib InformationsTechnologie Consult GmbH (SEIB ITC) Würzburg Bilfinger Berger AG Mannheim BAM Deutschland AG Standort Dresden Dresden IDS Scheer AG Saarbrücken RIB Information Technologies AG Stuttgart TransMIT Gesellschaft für Technologietransfer mbh Gießen TUD FIRST IWI SEIB BB BAM IDS RIB TMIT Koordinator Institut für Bauinformatik der Technischen Universität Dresden Postanschrift: Kontakt: Institut für Bauinformatik TU Dresden D Dresden Prof. Dr.-Ing. Raimar J. Scherer Telefon: +49/351/ Fax: +49/351/ Web: Seite 2 von 16

3 A-6.2 Konzeption des BauVOGrid-Portals Vorwort Dieser Bericht stellt die grundsätzliche Architektur des BauVOGrid-Portals dar. Der erste Teil des Berichtes stellt die zu Grunde liegenden Hardware- und Software Plattformen vor sowie die Änderungen, die sich bzgl. des Ergebnisses des Projektaudits ergaben. Im zweiten Teil wird die Authentifizierung und das Zusammenspiel mit dem VO Management der TU Dresden erläutert und die erarbeitete Authentifizierungs- und Autorisierungslösung vorgestellt. Im dritten Teil werden die verschiedenen Implementierungsmöglichkeiten exemplarisch dargestellt. Versionshistorie Version Beschreibung Autor(en) Datum 1.0 Erster Entwurf TOC P.Hornung Freigegebene Version SEIB ITC P.Hornung Freigegebene Endversion TUD Seite 3 von 16

4 Inhaltsverzeichnis Inhaltsverzeichnis 1. Prinzipielle Konzeption des BauVOGrid-Portals Ausgangssituation / Vorhandene Komponenten Einfluss des Auditergebnisses auf die Portalarchitektur 6 2. Authentifikation und Nutzung des VO-Management 7 3. Implementierung der einzelnen Module Composite Application Managed Browser NSF-Komponenten Zusammenfassung und Ausblick Referenzen Abbildungsverzeichnis 16 Seite 4 von 16

5 Prinzipielle Konzeption des BauVOGrid-Portals 1. Prinzipielle Konzeption des BauVOGrid-Portals 1.1. Ausgangssituation / Vorhandene Komponenten Die Firma SEIB ITC GmbH betreibt seit mehreren Jahren erfolgreich sog. Application Service Providing (ASP) Lösungen im Bereich der Baubranche. Die Schwerpunkte liegen dabei im Workflow- und Dokumentenmanagement. Diese existierende Plattform stellt die Grundlage der nachfolgend dargestellten Portallösung dar. Als Backendsystem wird die Groupwarelösung IBM Lotus Domino verwendet. Lotus Domino stellt ein dokumentenorientiertes, verteiltes Datenbanksystem mit sehr enger - Anbindung dar. Der Lotus Domino Server liefert mehrere Dienste. Er ist zunächst ein Datenbank-Server, der Notes-Dokumente an die Notes-Clients liefert. Dann gibt es einen Router-Server-Task (Task router ), der sowohl das native Domino Routing-Protokoll NRPC (Notes Remote Procedure Call) als auch das Simple Mail Transport Protokoll (SMTP) zum Senden von Mails ins Internet beherrscht. Der dazugehörige SMTP-Servertask (Task smtp ) dagegen sorgt dafür, dass Internet Mails auf diesem Server empfangen werden können. Ferner gehört auch ein HTTP-Server in Verbindung mit der SOAP - Engine Axis 1.4 zum Lieferumfang sowie weitere Server wie z. B. IMAP, POP3, LDAP. In den verschiedenen Datenbanken werden die Daten gemeinsam mit der Anwendungslogik und der Benutzeroberfläche abgelegt. Im Gegensatz zu anderen Datenbankensystemen können die Datenbanken auch ohne Verbindung zum Lotus Domino Server, nur mit dem Lotus Notes Client, genutzt und bearbeitet werden. Sobald wieder eine Verbindung zwischen Client und Server besteht werden die Änderungen der Daten je nach Konfiguration automatisch gemäß den definierten Verbindungsintervallen oder auch manuell abgeglichen. Dieses Konzept ist aus der Theorie der verteilten Datenbanken bekannt als Replikation. Wenn ein Notes-Client (oder ein Domino-Server) mit einem Domino-Server Datenbanken repliziert, werden nur neue und geänderte Dokumente übertragen. Bei Bedarf kann auch nur ein Teil der Gesamtdaten repliziert werden, dies kann dann über die Replizierparameter für jede Datenbank eingestellt werden (selektive Replikation). Der Replikationsmechanismus kann Änderungen an Dokumenten auf Feldebene erkennen und bei umfangreichen Dokumenten nur die geänderten Feldinhalte übertragen. Dadurch wird die zur Verfügung stehende Netzwerk-Übertragungskapazität effizient genutzt. Der Lotus Domino Server ist für eine Reihe von Plattformen wie z. B. Windows, Linux, AIX, Sun Solaris, AS/400 (OS/400), z/os und zlinux verfügbar. Die SEIB ITC GmbH verwendet jedoch ausschließlich die Windows-Variante. In der zurzeit benutzten Version von EPLASS werden keine Web-Services benutzt bzw. über das EPLASS System zur Verfügung gestellt. Seite 5 von 16

6 Prinzipielle Konzeption des BauVOGrid-Portals Der Zugriff wird über Citrix XenApp mit dem Lotus Notes Client bereitgestellt. XenApp verlagert dabei die Anwendungen in unser Rechenzentrum, wo sie zentral verwaltet und den Benutzern in allen Anwendungen als On-Demand-Service - in Form von gehosteten oder gestreamten Anwendungen - zur Verfügung gestellt werden. Abbildung 1 zeigt den grundsätzlichen Aufbau der Basis-Architektur der benutzten Portallösung. Abbildung 1 - Basis Architektur EPLASS 1.2. Einfluss des Auditergebnisses auf die Portalarchitektur Das Ergebnis des Projektaudits vom ergab eine Verschiebung der Projektziele (siehe Gutachterbericht). Die Nutzung von GRID-Ressourcen wurde stark zurückgefahren. Das Konsortium fokussierte sich auf das Pilotszenario Mängelmanagement mit minimaler Einbindung der GRID-VO. Die TU Dresden erstellte daraufhin ein eigenes VO Management, welches über Web- Service-Schnittstellen ansprechbar ist. Grundsätzlich wird die Kommunikation über die eingesetzten Systeme hinweg über Web- Services realisiert. Das Portal verfügt somit über keine direkte Anbindung an das D-GRID. Aus diesem Grund wurden auch keine ECLIPSE-Komponenten für die Zusammenstellung der Portalmodule verwendet. Dies ändert die Portalarchitektur nicht prinzipiell, beeinflusst jedoch die Realisierung der Autorisierungs-, Authentifizierungs- und Sicherheitskonzepte. Die semantische rollenbasierte Zugriffsrechte auf Daten und Services sind dadurch im Wesentlichen nicht betroffen. Die resultierende BauVOGrid Portalarchitektur ist in der nachfolgenden Abbildung 2 schematisch dargestellt. Seite 6 von 16

7 Authentifikation und Nutzung des VO-Management Abbildung 2 - Portal Architektur BauVOGrid 2. Authentifikation und Nutzung des VO-Management Das steuernde System der Virtuellen Organisation wird von der TU Dresden in Form eines VO-Webservices bereitgestellt. Das Portal synchronisiert die für die Anmeldung wichtigen Nutzerinformationen mit diesem Webservice. Das sind in unserem Beispiel Benutzername, Passwort und Organisationszugehörigkeit. Diese Informationen werden parallel von dem Portal lokal in einem eigenen Repository für die Überprüfung der Authentifikation und von dem VO-Service in der VO-Ontologie zur Überprüfung der Autorisierung gespeichert. Das Portal agiert damit als Identity Provider und bietet einen Authentication Service, während das VO-Management der TU Dresden in Form des VO-Webservices als Authorisation Service fungiert und die Zugriffsentscheidungen zu den Methodenaufrufen liefert. Die folgende Abbildung 3 zeigt schematisch die in BauVOGrid verwendete Sicherheits- Infrastruktur. Seite 7 von 16

8 Authentifikation und Nutzung des VO-Management Abbildung 3 BauVoGrid Sicherheits-Infrastruktur Die ZMMS- und Medien-Web-Services stellen ihre Dienste nur unter bestimmten Voraussetzungen zur Verfügung. Diese allgemeinen Anforderungen werden in WS-Policy beschrieben, Sicherheitsanforderungen in WS-Security Policy. Dabei werden die Standards WSDL, SOAP und WS Security berücksichtigt. Eine Minimalanforderung ist, dass der Client (Portal oder GWES) sich authentisiert. Um Missbrauch durch veränderte SOAP-Aufrufe zu verhindern, könnte der Webservice auch fordern, dass der SOAP-Body digital signiert ist oder SOAP-Elemente digital verschlüsselt werden. Der Abgleich der Benutzerdaten zwischen Portal und ZMMS erfolgt periodisch über einen Hintergrundagenten. Die folgende Auflistung stellt den Ablauf der Authentifikation bei der Anmeldung am Portal und dem darauffolgenden Methodenaufruf dar: Seite 8 von 16

9 Authentifikation und Nutzung des VO-Management 1. Der Benutzer meldet sich mit Benutzername und Passwort am Citrix WEBInterface an (siehe Abbildung 4 - Anmeldedialog CITRIX WEB-Interface). Abbildung 4 - Anmeldedialog CITRIX WEB-Interface 2. Das CITRIX SecureGateway überprüft Benutzername und Passwort und leitet nach erfolgreicher Validierung an die Startseite des CITRIX WEBInterface weiter. 3. Die Startseite des CITRIX Webinterfaces zeigt dem Anwender die freigegebenen Applikationen. In unserem Beispiel das BauVOGrid-Portal (siehe Abbildung 5 - Applikationsseite CITRIX WEB-Interface). Abbildung 5 - Applikationsseite CITRIX WEB-Interface Seite 9 von 16

10 Authentifikation und Nutzung des VO-Management 4. Nach Doppelklick auf das BauVOGrid-Applikationssymbol, werden die Benutzerinformationen an Lotus Domino weitergeleitet. Es erfolgt eine weitere Überprüfung der Informationen im Hinblick auf die Rollen- und Projektzugehörigkeit. Die individualisierte Eingangsseite des Anwenders wird im BauVOGrid-Portal angezeigt (siehe Abbildung 6 - Startseite BauVOGrid-Portal). 5. Von dem Portal können nun SOAP-Anfragen direkt an das ZMMS, an den Medien- Service oder den BPO-Service gestellt werden. Ebenfalls ist es möglich den Grid Workflow Execution-Service(GWES) anzusprechen und mit diesem Workflows auszuführen. Dabei werden jeweils die Nutzer-ID als Security-Token im SOAP-Header mitgegeben (siehe Listing 1). Der GWES schickt dann seinerseits abhängig von den Workflow- Schritten die SOAP-Anfrage direkt an das ZMMS oder Medien-Service unter Mitgabe der Nutzer-ID. <soapenv:envelope xmlns:soapenv=" xmlns:q0=" xmlns:xsd=" xmlns:xsi=" <soapenv:header> <wsse:security xmlns:wsse=" <wsse:usernametoken Id="UserID"> <wsse:username>000001</wsse:username> </wsse:usernametoken> </wsse:security> </soapenv:header> <soapenv:body> <q0:existsdefect> <q0:defectid>0815</q0:defectid> </q0:existsdefect> </soapenv:body> </soapenv:envelope> Listing 1 SOAP Header mit Übergabe der User-ID 6. Das ZMMS lässt vor der Abarbeitung einer Anfrage die Berechtigung durch den VO- Service prüfen. Dieser ermittelt mittels der Nutzer-ID und des betreffenden Mangels die Rolle des Nutzers und ermittelt im Anschluss daran die Zugriffsrechte. Dadurch ist eine rollenbasierte feingranulare kontextsensitive Autorisierung möglich. Seite 10 von 16

11 Authentifikation und Nutzung des VO-Management Abbildung 6 - Startseite BauVOGrid-Portal Bei jedem Aufruf einer Methode des Webservices des Zentralen Managementsystems (ZMMS), des Medienmanagementsystems (MedienMS) oder des Virtuellen Organisationsmanagements (VO) wird im SOAP-Header eine eindeutige User-ID übergeben, mit Hilfe derer der VO- Management-Webservice die Zugriffsrechte des entsprechenden Anwenders ermittelt. Jede Methode der oben genannten WebServices erfragt bei dem VO-Management-Webservice, ob der aufrufende Nutzer überhaupt die nötigen Berechtigungen zur Abarbeitung besitzt. In Listing 1 SOAP-Header wird der entsprechende Auszug aus dem Header einer SOAP- Anfrage dargestellt. Wir verwenden den in der WS-Security definierten <wsse : Security>-Block kann prinzipiell mehrfach in einem SOAP-Header auftauchen, wenn bei der Bearbeitung einer SOAP-Nachrichten mehrere Stationen beteiligt sind. Wir gehen davon aus, dass nur ein Block existiert. Wir verwenden den UsernameToken als unsigned Security Token und legen in der WS- SecurityPolicy fest, dass der Client sich über ein SecurityToken im SOAP Security Header authentisieren muss. Client ist hierbei das GWES oder das Portal. Im Rahmen der Pilotanwendung wird auf eine Verschlüsselung der Datenübertragung via SSL/TLS explizit verzichtet, da hier Standardmechanismen eingesetzt werden, die im Rahmen dieses Projektes nur zusätzliche Kapazitäten gebunden hätten. Desweiteren wird die mögliche Verschlüsselung von SOAP-Inhalten nicht verwendet. Im Produktivbetrieb sind natürlich diese Funktionalität zu implementieren. Seite 11 von 16

12 Implementierung der einzelnen Module 3. Implementierung der einzelnen Module 3.1. Composite Application Die Portaldatenbank ist als sogenannte Composite Application ausgebildet. Dabei handelt es sich um lose gekoppelte Komponenten aus verschiedenen Anwendungen, die ähnlich dem Programmiermodell des WebSphere Portal 6 miteinander verbunden sind. Diese Art der Integration von Komponenten lassen sich auch auf dem Server definieren und entsprechend voreingestellten Profilen auf viele Clients verteilen. Bei diesen Anwendungen lassen sich auch unterschiedliche Web Services nach Belieben zusammenfassen, wobei sowohl Eclipse-Komponenten als auch im Domino Designer realisierte NSF-Komponenten verwendet werden können, die entsprechende Web Services bereitstellen. Die Composite Applications ist die Umsetzung des SOA-Konzepts (Service Oriented Architecture) für Notes/Domino die Verbindung von Komponenten über Services in einer flexiblen Weise, wodurch die Wiederverwendbarkeit von Komponenten und die Modularität von Anwendungen erhöht werden. Die Komponenten werden in einem oder mehreren Design-Elementen beschrieben, die man als Composite Applications -Design-Elemente bezeichnet. Die Struktur dieser Komponenten wird in WSDL-Dateien beschrieben und ist dort von zentraler Bedeutung. Anhang 2 Composite Application WSDL zeigt exemplarisch einen Teilauszug der WSDL-Beschreibung des Portals. Im Rahmen der Composite Applications hat man unterschiedliche Möglichkeiten, externe Module in eine Portalumgebung zu integrieren. Die unterschiedlichen Möglichkeiten werden hier an Hand von umgesetzten Beispielen erläutert Managed Browser Eine einfache Möglichkeit externe Zielanwendungen einzubinden, besteht darin, Diese innerhalb eines fest definierten Ansichtsbereiches des Portals mittels eines sog. Managed Browsers einzubinden. Diese Variante ist dann sinnvoll, wenn die Zielanwendung bereits ein vollständiges WEB-Interface besitzt und kein Datenaustausch zwischen den unterschiedlichen Modulen erforderlich ist. Als Beispiel wird das im Rahmen der Entwicklung eingesetzte Web Interface des TestBeds der TU Dresden als Managed Browser dargestellt (siehe Abbildung 6 - Startseite BauVOGrid- Portal). Seite 12 von 16

13 Implementierung der einzelnen Module Abbildung 7 - Einbindung des TestBeds durch einen Managed Browser Abbildung 8 - Composite Application Editor Seite 13 von 16

14 Implementierung der einzelnen Module 3.3. NSF-Komponenten Tiefer gehende Integrationen der beteiligten Systeme, z.b. Nutzung von Webservices, Darstellung von SPARQL Abfragen, Eingabemasken usw. werden mit den systemeigenen integrierten Entwicklungstools von Lotus Notes als sogenannte NSF Komponenten realisiert. NSF-Komponenten sind Elemente einer Lotus Notes-Anwendung, die in einer Verbundanwendung Composite Applications eingesetzt werden. Mit der Funktion "Composite Application Editor" können, ohne die vorhandene Notes-Anwendung ändern zu müssen, die Ansichten, Masken, Dokumente und andere Elemente der Notes-Anwendung als Komponenten eingesetzt werden. Eine Notes-Komponente ist ein Link auf eine bestimmte Ansicht, eine Rahmengruppe, ein Dokument oder eine andere Gestaltungskomponente in einer Notes-Datenbank. Dieselbe Notes- Datenbank kann mehrere Komponenten enthalten und diese Komponenten können in mehreren Verbundanwendungen verwendet werden. Diese Mehrfachverwendung von Komponenten erlaubt es sehr schnell die unterschiedlichen Anforderungen der Nutzergruppen zu realisieren. Als Beispiel sei hier die Darstellung der Mangelrecords bzw. SPARQL Abfragen für die einzelnen Userrollen erwähnt. Abbildung 9 - Einbindung des Mängelmanagementsystems des GU über eine NSF-Komponente Seite 14 von 16

15 Zusammenfassung und Ausblick 4. Zusammenfassung und Ausblick Im vorliegenden Beitrag wurde aufgezeigt, wie das Projektportal im Gesamtsystem eingebunden wird, welche Rolle es bei der Authentisierung der Nutzer spielt und wie es mit dem, für die Authorisierung zuständigen VO-Service kommuniziert. Es wurde die Lotus-Lösung Composite Application vorgestellt, welche eine dynamische, direkte und robuste Einbindung von externen webbasierten Anwendungen bietet. Des Weiteren wurde die NSF-Komponenten-Lösung vorgestellt, mit deren Hilfe die WebServices des zentralen Mängelmanagement und des Medienmanagement sowie des BPO-Services der TU Dresden direkt aus dem Portal angesprochen werden können. Durch den vorliegenden Ansatz wird es ermöglicht, das Portal als ausführende Plattform zu betrachten, auf der alle Daten des Pilotprojektes bearbeitet werden können. Zukünftiger Forschungsbedarf besteht hinsichtlich der Verbesserung der Stabilität der Datenübertragung durch Datenkomprimierung bei der Übertragung und dem Zusammenfassen von Objekten, in unserem Beispiel Mangellisten. Die vorgestellten Dienste wurden prototypisch für den Testbetrieb Im Rahmen der Pilotanwendung implementiert. Dabei wurde auf Verschlüsselung der SOAP-Inhalte und zusätzliche Sicherung der Übertragungswege via SSL/TLS verzichtet. Im Produktivbetrieb, wenn tatsächlich sensitive Daten übetragen werden, sind solche Funktionalitäten für das Vertrauen der Partner geradezu notwendig. Dafür gibt es genügend ausgereifte Lösungen, welche nicht im Fokus des Projektes lagen. Seite 15 von 16

16 Referenzen 5. Referenzen IBM Lotus Domino IBM Lotus Notes CITRIX XENApplication Server 6. Abbildungsverzeichnis Abbildung 1 : Basis Architektur EPLASS Abbildung 2 : Portal Architektur BauVOGrid Abbildung 3 : Anmeldedialog CITRIX WEBInterface Abbildung 4 : Applikationsseite CITRIX WEBInterface Abbildung 5 : Startseite BauVOGrid-Portal Abbildung 6 : Einbindung des TestBeds durch einen Managed Browser Abbildung 7 : Einbindung des Mängelmanagementsystems des GU über eine NSF-Komponente Seite 16 von 16