4.1 Grundlagen Vor- und Nachteile

Transkript

1 Jeder hat sie und verlieren wir sie, ist der Ärger groß: Ohne unsere persönliche Kennwortliste sind wir inzwischen machtlos. Single Sign-on verspricht ein Ende der Passwortinflation, muss sich aber zugleich immer vielschichtigeren Anforderungen der unternehmerischen Praxis stellen. Erfahren Sie in diesem Kapitel, wie Sie mit SAP NetWeaver in heterogenen Systemlandschaften und über Unternehmensgrenzen hinweg das Konzept der einmaligen Anmeldung erfolgreich umsetzen. 4 Single Sign-on Nahezu alle IT-gestützten Unternehmensprozesse setzen bestimmte Berechtigungen voraus, um Arbeitsabläufe zu kontrollieren und nachvollziehbar zu machen. Gerade in historisch gewachsenen IT- Infrastrukturen findet man daher eine Vielzahl von individuellen Ansätzen der Zugriffsregelungen, was dazu führt, dass die Anzahl der Benutzerkonten je Mitarbeiter durchschnittlich im zweistelligen Bereich liegt und stetig wächst. Verstärkt wird dieser Trend durch die zunehmende Integration von Anwendungen und Systemen bei Partnern, Lieferanten und Kunden. Motivation Der beträchtliche Aufwand, der für die Verwaltung der Benutzerprofile notwendig ist, belastet nicht nur das IT-Budget, sondern bedeutet vor allem auch ein Sicherheitsrisiko im Unternehmen, das oftmals unterschätzt wird. Schnell stellen Anwenderschaft und Management die vielbeschworenen Vorteile einer engen Verzahnung zwischen der IT und Geschäftsprozessen wie Kosteneinsparung und Effizienzsteigerung in Frage, wenn die Sicherheitsmechanismen die Abläufe komplizierter machen, ohne dass eine Steigerung des Sicherheitsniveaus nachweisbar ist. Anwender entwickeln dann schnell Strategien, wie sie die störenden Schutzvorkehrungen umgehen können. Im schlimmsten Fall gefährden sie dabei die Systemsicherheit durch unachtsamen Umgang mit Benutzernamen und Passwörtern und machen sich so ungewollt zum engsten Verbündeten des Angreifers. 163

2 4 Single Sign-on 4.1 Grundlagen Einen Ausweg aus diesem Dilemma versprechen Konzepte, die die Komplexität einer Sicherheitsinfrastruktur aus Sicht des Anwenders und Administrators reduzieren, während sie das Sicherheitsniveau aufrechterhalten oder gar verbessern. Ein prominenter Vertreter dieser Kategorie ist das sogenannte Single Sign-on (SSO). Das Konzept des Single Sign-on beruht auf der Idee, dem Benutzer über eine einmalige Anmeldung den Zugriff auf alle Anwendungen zu ermöglichen, für die er eine Berechtigung besitzt. Die Authentifizierungsdaten aus der Erstanmeldung werden dazu genutzt, ihn ohne erneute Interaktion bei den anderen Anwendungen anzumelden Vor- und Nachteile Arbeitserleichterung und Sicherheitsgewinn Risiken Vergegenwärtigt man sich in diesem Zusammenhang die Ergebnisse der von der Fachzeitschrift InformationWeek durchgeführten Studie IT-Security 2006 (siehe liegen die Vorteile von Single Sign-on klar auf der Hand: Nach Aussage von insgesamt 827 befragten Sicherheitsverantwortlichen verdoppelte sich die Zahl der Fälle von Passwortmissbrauch in den Unternehmen auf 6,8 Prozent gegenüber dem Vorjahr. Der Einsatz von Single Sign-on wirkt dieser Entwicklung entgegen, da sich Benutzer hier nur noch ein Passwort merken müssen, was die tägliche Arbeit mit den Anwendungen im Unternehmen deutlich erleichtert. Die Notwendigkeit zur Pflege der berüchtigten Passwortlisten wird ebenso überflüssig wie die Vergabe identischer Kennworte in allen Systemen eine Maßnahme, die oftmals der letzte Rettungsanker der Anwender im immer dichter werdenden Passwortdschungel ist. Neben der Zeitersparnis durch die einmaligen Authentifizierung ergibt sich noch ein weiterer Sicherheitsgewinn: Das Passwort (oder jede andere Form von geheimer Sicherheitsinformation) wird nur einmal pro Sitzung, nämlich bei der Erstanmeldung übertragen, was das Risiko des Ausspionierens der geheimen Daten erheblich verringert. SSO-Verfahren bergen allerdings auch Risiken: Sollte es einem Angreifer gelingen, in den Besitz der SSO-Authentifizierungsdaten zu gelangen, so erhält er den vollen Zugriff auf alle damit abgesicherten Ressourcen. Die Übertragung der Authentifizierungsdaten sollte daher ausschließlich über verschlüsselte Verbindungen erfolgen. 164

3 Grundlagen 4.1 Auch muss gewährleistet sein, dass die verwendete Methode für die Einmalanmeldung in keinem Fall schwächer ist als die existierenden Mechanismen ohne Single Sign-on. Darüber hinaus entsteht durch die Einführung einer zentralen Authentifizierungskomponente eine kritische IT-Ressource, deren Verfügbarkeit höchste Priorität gewinnt, und die auch unter starker Last nicht selbst zum Sicherheitsrisiko werden darf Lösungsansätze Ein typischer Lösungsansatz für den Aufbau einer SSO-Infrastruktur besteht darin, ein Netz aus vertrauenswürdigen Anwendungen und Diensten zu bilden, die über gemeinsame Authentifizierungsdaten für die Benutzer verfügen. Grundlage dafür ist in der Regel eine Public Key Infrastruktur (PKI, siehe Abschnitt 2.4,»Public-Key-Infrastruktur«), in der sich die Anwendungen über X.509-Zertifikate gegenseitig authentifizieren. Prinzipiell könnte man auch die Benutzer mit Zertifikaten ausstatten, damit diese sich gegenüber den Anwendungen ausweisen. Dagegen sprechen allerdings in den meisten Fällen praktische Erwägungen, da die Verwaltung individueller Benutzerzertifikate in erster Linie einen hohen administrativen Aufwand bedeutet und zudem mit erheblichen Kosten für den Betreiber der PKI verbunden ist. Als leichtgewichtigere Alternative zu Zertifikaten kommen bei den meisten Ansätzen im SSO-Umfeld sogenannte Anmeldecookies zum Einsatz. Ein solches Anmeldecookie wird dem Benutzer nur nach einer zuvor erfolgreich durchgeführten Anmeldung über herkömmliche Mechanismen wie Benutzername und Passwort durch eine zentrale Komponente im Netzwerk ausgestellt, die eine unternehmensweite Sicht über die Identitäten und die ihnen zugeordneten Benutzerkennungen liefert (siehe Abschnitt 5.1.4,»Identity-Management-Systeme«). PKI Anmeldecookies Einmal im Besitz eines gültigen Anmeldecookies, wird es vom Client (z.b. dem Browser des Benutzers) automatisch an die Zielanwendungen übermittelt. Diesen bleibt es nun überlassen, eine Authentifizierungsentscheidung auf der Grundlage der empfangenen Informationen zu fällen. Vertraut die jeweilige Anwendung der durch das Anmeldecookie getroffenen Aussage, dass sich sein Besitzer zuvor erfolgreich an dem zentralen Identity Provider (IdP) angemeldet hat, 165

4 4 Single Sign-on wird dem Benutzer der Zugriff gewährt. Grundsätzliche Voraussetzung dafür ist ein Vertrauensverhältnis zwischen dem Identity Provider und den Anwendungen, das mittels einer PKI und des Austauschs von Zertifikaten außerhalb des eigentlichen Single-Sign-on- Prozesses etabliert werden kann. Ob über den Besitz des Anmeldecookies hinaus noch weitere Informationen vom Benutzer für eine erneute Authentifizierung notwendig sind, bleibt den jeweiligen Anwendungen überlassen. Selbstverständlich muss auch das Anmeldecookie selbst gegen unberechtigten Zugriff und Veränderungen geschützt werden. Gelangt es in die Hände eines Dritten, so darf es diesem nicht möglich sein, sich mit dem Anmeldecookie im Namen seines rechtmäßigen Besitzers bei den für ihn freigegebenen Anwendungen anzumelden. Um dies zu garantieren, werden bei den meisten Verfahren folgende Sicherheitsvorkehrungen getroffen: Dem Anmeldecookie darf wie einem X.509-Zertifikat in der Regel nur eine zeitlich begrenzte Gültigkeit vom Identity Provider bescheinigt werden. Der Identity Provider signiert das Anmeldecookie mit seinem privaten Schlüssel und schützt es so gegen unberechtigte Manipulation. Das Anmeldecookie enthält keine geheimen Anmeldeinformation, wie z.b. das bei der Erstanmeldung verwendete Passwort des Benutzers. Das Anmeldecookie enthält nur die für den Empfänger absolut notwendigen Identitätsinformationen über den Benutzer. Sicherheitskritische Informationen wie Kreditkarten- oder Sozialversicherungsnummern sollten nicht über das Netzwerk übertragen werden. Die Übermittlung des Anmeldecookies zwischen Identity Provider, Benutzer und Zielanwendung erfolgt über eine sichere Verbindung Portale Dem Wunsch der Anwender nach vereinfachten Abläufen wird man jedoch nicht alleine durch eine einmalige Anmeldung gerecht. Vielmehr nimmt der Benutzer eine verbesserte Integration der bestehen- 166

5 Single Sign-on im Intranet 4.2 den Anwendungen durch die Zusammenführung der Benutzungsoberflächen unter einem zentralen Zugriffspunkt wahr. So dienen die Investitionen in eine SSO-Infrastruktur häufig als idealer Wegbereiter für eine weiterführende Konsolidierung der heterogenen Anwendungslandschaft unter einer homogenen Benutzungsoberfläche, die dem Benutzer eine rollenbasierte und personalisierbare Sicht auf alle für ihn relevante Informationen erlaubt. Diese Portale zu den Unternehmensdaten und Applikationen organisieren die einzelnen Anwendungen unter einer einheitlichen Oberfläche und gemeinsamen Navigation in speziellen Unterfenstern, in denen entweder das komplette User Interface oder nur der für den jeweiligen Benutzer wichtige Ausschnitt auf die Funktionalität der Anwendungen angezeigt wird. Im SAP NetWeaver Portal heißen diese Komponenten iviews. Ihr Einsatzgebiet reicht von der einfachen Darstellung einer statischen Webseite bis zur Integration von Anwendungen im Backend. Alle Anwendungen können über die von der Portalsoftware bereitgestellten Basisdienste Daten miteinander austauschen und tragen auf diese Weise zu einer verbesserten Prozessorientierung bei. Selbstverständlich lässt sich über eine manuelle Anmeldung an allen Anwendungen im Portal nicht die Illusion des transparenten Zugriffs auf die heterogene Systemlandschaft im Hintergrund aufrechterhalten. Single Sign-on nimmt daher in Portalen eine zentrale Funktion ein, die sich aber nicht nur auf die einmalige Anmeldung der eigenen Mitarbeiter an den internen Unternehmensanwendungen beschränkt. Neben den klassischen Mitarbeiterportalen haben sich sogenannte Geschäftskunden- und Lieferantenportale etabliert, die sich auf die zwischenbetrieblichen Prozesse im B2B-Sektor (Business-to-Business) konzentrieren. Hier werden über die Infrastruktur des Portals speziell auf die Zielgruppe ausgerichtete Anwendungen, wie beispielsweise Produktkataloge und Trackingsysteme zur Statusverfolgung von Dokumenten oder Gütern, zur Verfügung gestellt, um darüber die Marketing-, Vertriebs- und Serviceprozesse zu optimieren. iviews Portaltypen 4.2 Single Sign-on im Intranet Bei der Einführung von Single Sign-on für die einmalige Anmeldung an Anwendungen im internen Unternehmensnetzwerk (Intranet) 167

6 4 Single Sign-on besteht in der Regel der Vorteil, dass durch existierende Sicherheitsrichtlinien in der Organisation von bestimmten Annahmen bezüglich der Infrastruktur auf den Desktops der Anwender sowie der Serverlandschaft ausgegangen werden kann. So ist beispielsweise unternehmensweit nur ein bestimmter Browser mit einheitlichen Sicherheitseinstellungen im Einsatz. Außerdem sind keine Firewalls zwischen den Desktops und Applikationsservern zu überwinden, die den Einsatz bestimmter Protokolle verbieten und somit die Auswahl der verfügbaren Technologien für Single Sign-on einschränken würden. Darüber hinaus können einheitliche Namenskonventionen dafür sorgen, dass selbst bei Existenz mehrerer Benutzerdatenbanken oder Verzeichnisdienste die Anmeldenamen gleich lauten oder zumindest einem bestimmten Schema folgen, das ein aufwendiges Mapping zwischen den Systemen vereinfacht oder sogar unnötig macht. Auch die Einrichtung von Vertrauensbeziehungen für das Single Sign-on zwischen den Systemen in einem gemeinsamen Verbund macht in Intranet-Szenarien häufig weniger Kopfzerbrechen, da die administrative Hoheit in den Händen einer Organisation liegt. Im Idealfall gehören alle für das Single Sign-on vorgesehenen Systeme einer gemeinsamen technischen Domäne an. Laufen die Anwendungen dann sogar noch auf dem gleichen Server, kann die Bereitstellung von SSO-Funktionalität so einfach funktionieren wie in Abschnitt im Zusammenhang mit J2EE Security Policy Domains beschrieben. Im Zuge der Weiterentwicklung des Unternehmensszenarios wird im Folgenden das SAP Logon Ticket beschrieben, das ursprünglich mit der Entwicklung des mysap.com Workplace eingeführt wurde und ein genau auf die oben beschriebenen Rahmenbedingungen zugeschnittenes SSO-Verfahren in SAP NetWeaver darstellt. Der Einsatz des SAP Logon Tickets in einer heterogenen Systemlandschaft wird im Rahmen des Unternehmensszenarios und der zugehörigen Übung 3 in Abschnitt (»SSO-Integration von AddressBook in das Mitarbeiterportal«) behandelt SAP Logon Ticket Cookies Beim SAP Logon Ticket handelt es sich um ein HTTP-Cookie, dessen Daten digital signiert sind. Neben dem üblichen Verwendungszweck 168

7 Single Sign-on im Intranet 4.2 von Cookies zur Verwaltung von Sitzungsinformationen und zur Überbrückung des zustandslosen Charakters von HTTP eignen sich die temporär im Browser gespeicherten Textdateien auch für die einmalige Anmeldung an mehreren Systemen in einer gemeinsamen Domäne, wie es beim SAP Logon Ticket der Fall ist. Bevor der Benutzer in den Besitz eines solchen Tickets kommt, muss er sich mittels eines der gängigen Authentifizierungsverfahren wie z.b. Benutzername und Passwort oder seinem persönlichen Zertifikat an einem SAP-System anmelden, das für die Ausgabe der Tickets konfiguriert ist. Mit dieser Anmeldeinformation generiert der Server das SAP Logon Ticket und sendet es mit der HTTP Response als Cookie an den Browser zurück. Sofern vom Benutzer keine Einschränkungen im Browser im Umgang mit Cookies in den Sicherheitseinstellungen konfiguriert wurden, wird das SAP Logon Ticket unter dem Namen MYSAPSSO2 im lokalen Cookie-Cache im Browser maximal für die Dauer seiner Gültigkeit gespeichert, die in der Regel auf acht Stunden begrenzt ist. Schließt der Benutzer den Browser vor Ablauf des Verfallsdatums, so wird das Ticket ebenfalls gelöscht. Abbildung 4.1 zeigt die Vergabe des SAP Logon Tickets im HTTP Header mit der Set-Cookie-Direktive nach erfolgreicher Authentifizierung an einem SAP NetWeaver Portal, das typischerweise in einer SAP-Systemlandschaft die Rolle des Ticketausstellers übernimmt. Der HTTP-Datenstrom zwischen Browser und Webserver wurde mithilfe des HTTP-Monitoring-Tools HttpWatch ( aufgezeichnet. Abbildung 4.1 Vergabe eines SAP Logon Tickets (MYSAPSSO2) mit der Angabe Set-Cookie im Header der HTTP Response 169

8 4 Single Sign-on Typisches Einsatzgebiet: Intranet Schutz vor Replay- Attacken Vergleich zu herkömmlichen Methoden Selbstverständlich unterliegt das SAP Logon Ticket wie jedes andere Cookie auch einigen technischen Restriktionen, die aus Gründen des Datenschutzes und der Sicherheit getroffen wurden. Neben der maximalen Größe von 4 KB zählt dazu vor allem, dass der Browser das Ticket nur an das ausstellende System (z.b. portal.mycompany.net) oder an ein benachbartes System in der gleichen DNS- Domäne 1 (z.b. ssologin.mycompany.net) mit jedem weiteren HTTP Request schicken darf. Die Angabe der zulässigen Domäne erfolgt bei der Vergabe des Tickets über das Cookie-Attribut Domain. Daher zählt das Intranet im Unternehmen zu den typischen Einsatzgebieten cookiebasierter SSO-Verfahren wie dem SAP Logon Ticket. Für die Umsetzung von unternehmensübergreifenden SSO-Szenarien bieten sich andere Alternativen an, auf die in Abschnitt 4.3,»Unternehmensübergreifendes Single Sign-on«, im Zusammenhang mit SAML eingegangen wird. Da es in der Natur des Cookies liegt, vom Browser wiederholt mit jedem Request an den Server geschickt zu werden, unterliegt dieser Mechanismus grundsätzlich dem Risiko der unerlaubten Aufzeichnung und Wiedereinspielung des Datentransfers durch Dritte. Konkret könnte eine Kopie des SAP Logon Tickets dafür genutzt werden, sich unberechtigten Zugang zu den geschützten Ressourcen zu verschaffen. Dieser auch als Replay-Attacke bezeichnete Angriff stellt beim Einsatz des SAP Logon Tickets eine ernstzunehmende Bedrohung dar, die nur durch eine Verschlüsselung auf der Transportschicht zwischen dem rechtmäßig autorisierten Client und dem Server verhindert werden kann und sollte. Herkömmliche Authentifizierungsverfahren wie die HTTP Basic Authentication sind jedoch den gleichen Risiken ausgesetzt: Benutzername und Passwort werden mit jedem Request als Base64-codierter String im HTTP-Header ungesichert über die Leitung geschickt. Hier stellt das SAP Logon Ticket im direkten Vergleich eindeutig die sicherere Variante dar, weil es keinerlei Anmeldedaten seines Besitzers enthält. Bewusst wird auch auf die Übermittlung von Passwörtern oder anderer geheimer Daten im Ticket verzichtet, da immer 1 Der Domain Name Service (DNS) ist ein Dienst in TCP/IP-Netzen, dessen Hauptaufgabe die Umsetzung von Host- und Domainnamen in die zugehörigen IP-Adressen ist. Im Internet basiert der DNS auf einer weltweit verteilten, hierarchisch organisierten Datenbank. 170

9 Single Sign-on im Intranet 4.2 von einem zuvor etablierten Vertrauensverhältnis zwischen dem ausstellenden und dem empfangenen System ausgegangen wird. Der Empfänger kann sich darauf verlassen, dass sich der Besitzer des Tickets zuvor ordnungsgemäß beim Herausgeber authentifiziert hat, was dieser durch seine digitale Unterschrift im Ticket beglaubigt. Das passende Zertifikat zum privaten Signaturschlüssel des Ausstellers muss vor dem ersten Anmeldevorgang allen Systemen, die sich mit dem Herausgeber in einem gemeinsamen SSO-Verbund befinden, über einen sicheren Weg zugestellt und installiert werden Verifikation von SAP Logon Tickets in Fremdsoftware Für externe, nicht auf einem SAP-Anwendungsserver betriebene Applikationen stellt SAP eine Verifikationsbibliothek (SAPSSOEXT) zur Verfügung. Die Software liegt als dynamisch ladbare Bibliothek für Windows, einige Unix-Derivate, OS/400 und z/os vor und kann vom SAP Service Marketplace im Software Distribution Center (http//service.sap.com/swdc) unter Download Support Packages and Patches Entry by Application Group Additional Components SAPSSOEXT heruntergeladen werden. Da für die Signatur des Tickets ein Public-Key-Verfahren verwendet wird, benötigt SAPSSOEXT selbst wiederum die SAP-Kryptobibliothek SAPSECULIB, die an gleicher Stelle zum Download zur Verfügung gestellt wird. SAPSSOEXT Mit SAPSSOEXT lässt sich die Gültigkeit eines in der Fremdsoftware empfangenen SAP Logon Tickets überprüfen, d.h. ob die im Ticket enthaltenen Daten als authentisch gelten können. Prinzipiell liefert die Hauptfunktion der Bibliothek daher auch nur eine Antwort mit zwei Optionen zurück: Ein Ticket ist gültig oder nicht. Ausschlaggebend dafür ist der unverfälschte Zustand der im Ticket enthaltenen Daten, der über die Signatur des Ausstellers überprüft wird, sowie ein noch nicht verstrichenes Ablaufdatum. Daraufhin kann das Zielsystem eine im Sinne von Single Sign-on automatisierte Authentifizierungsentscheidung treffen. Fällt die Prüfung negativ aus, liefert ein Fehlercode der Bibliotheksfunktion nähere Informationen zu den Ursachen. Wird das Ticket als gültig betrachtet, werden alle für die Weiterverarbeitung relevanten Daten im Ticket an den Aufrufer zurückgeliefert. Hierzu zählen: 171

10 4 Single Sign-on Benutzername im ausstellenden System Name des ausstellenden SAP-Systems (SID) Verwendetes Authentifizierungsschema (Authentication Schema) bei der Anmeldung am ausstellenden System Gültigkeitsdauer des Tickets in Sekunden Signatur des ausstellenden Systems Der Empfänger des Tickets wird diese Informationen in der Regel dazu nutzen, eine endgültige Authentifizierungsentscheidung noch zusätzlich davon abhängig zu machen, ob das Ticket von einem vertrauenswürdigen System ausgestellt wurde. Findet sich der Name des Ausstellers (Distinguished Name, DN) nicht in einer entsprechenden Zugriffskontrollliste (Access Control List, ACL), sollte dem Benutzer der Zugriff verweigert werden Unternehmensszenario: SSO-Integration einer externen Anwendung in das Mitarbeiterportal Dem Wunsch der Anwender, mithilfe von SAP NetWeaver ein internes Mitarbeiterportal für den zentralen Zugriff auf alle relevanten Anwendungen zu schaffen, leistet das Management von SecureSale Folge. Die mit dem Auftrag für das neue Projekt Mitarbeiterportal formulierten Ziele weisen klar auf, dass insbesondere von den neuen Möglichkeiten einer einmaligen Anmeldung über Single Sign-on Gebrauch gemacht werden soll. Bei einer regelmäßig durchgeführten, internen Umfrage steht der»passwortdschungel«immer wieder ganz oben auf der Liste der Probleme, die den Anwendern die tägliche Arbeit mit den IT-Systemen besonders erschweren. Geradezu explosionsartig hat sich in den vergangenen Jahren die Anzahl der dezentral verwalteten Anwendungen entwickelt. Nicht alle Projekte liefen unter der Leitung der zentralen IT-Abteilung bei SecureSale, was dazu führte, dass externe Berater und Architekten aus den Fachabteilungen die unternehmensweit gültigen Standards für die Benutzerverwaltung nicht immer einhielten. Viele Anwendungen besitzen daher ihre eigene Benutzerdatenbank oder replizieren bestenfalls die Stammdaten aus dem zentralen Benutzerverzeichnis, um sie lokal um eigenen Rollen und Berechtigungen zu ergänzen. Jede neue Anwendung dieser Kategorie bedeutete zugleich einen weiteren Eintrag auf den persönlichen 172

11 Single Sign-on im Intranet 4.2 Passwortlisten der Mitarbeiter. Dies wurde von niemandem begrüßt, bislang aber als notwendiges Übel akzeptiert. Das neue Projekt eröffnet Ihnen nun die Möglichkeit, hier endlich für Ordnung zu sorgen. Stellvertretend für viele dieser Insel-Lösungen steht die Anwendung AddressBook, mit der jeder Mitarbeiter nach den Kontaktdaten seiner Kollegen wie der -Adresse oder Telefonnummer suchen kann. AddressBook besteht aus einer einfachen Suchmaske, in der man entweder den Namen oder die Personalnummer der gesuchten Person einträgt, um deren vollständige Kontaktdaten zu erhalten. Da es sich hierbei aus Sicht des Unternehmens um schützenswerte Daten handelt, ist der Zugriff auf die Anwendung nur Mitarbeitern von SecureSale vorbehalten, die sich entsprechend vor der Nutzung mit einem Benutzername und Passwort über Basic Authentication anmelden müssen. AddressBook Technisch betrachtet ist AddressBook eine auf JSPs und Servlets basierte J2EE-Applikation, die auf dem weit verbreiteten Webcontainer Tomcat der Apache Software Foundation ( betrieben wird. Da noch viele andere innerbetriebliche Anwendungen bei SecureSale diese Ablaufumgebung nutzen, wäre eine Portierung aller Anwendungen auf den SAP NetWeaver Application Server Java trotz Konformität zum J2EE-Standard im ersten Schritt zu aufwendig und würde den sehr knappen Zeitrahmen für das Projekt sprengen. Stattdessen möchten Sie erreichen, dass Anwendungen wie Address- Book in ihrer existierenden Ablaufumgebung in die Lage versetzt werden, von der einmaligen Anmeldung im Mitarbeiterportal über das SAP Logon Ticket zu profitieren. Außerdem sollen keine Änderungen am Quellcode der existierenden Anwendung erforderlich werden, da der damit verbundene Aufwand ebenfalls die Einhaltung der Projektziele hinsichtlich Zeit und Kosten gefährden würde. Für die Integration des neuen, auf dem SAP Logon Ticket basierenden Anmeldeverfahrens entscheiden Sie sich für die Implementierung eines JAAS Login Modules (siehe Abschnitt 3.4.2,»Login- Module und Login-Modul-Stacks), das die externe Verifikationsbibliothek SAPSSOEXT verwendet, um damit die folgenden Aufgaben durchzuführen: Minimal-invasive Integration JAAS mit SAPSSOEXT 173

12 4 Single Sign-on Auslesen des Tickets aus dem Request des Benutzers Überprüfung der digitalen Signatur des Herausgebers Überprüfung der Gültigkeitsdauer des Tickets Moduloptionen Darüber hinaus soll das Login-Modul noch die folgenden Optionen bieten, um wichtige Laufzeitparameter zu konfigurieren sowie ergänzende Sicherheitsprüfungen bei der Authentifizierung vornehmen zu können: trustedissuer Listet vertrauenswürdige Herausgeber auf, deren eindeutiger Name mit dem überlieferten Distinguished Name (DN) im Zertifikat des Tickets verglichen wird. authscheme Legt das für die Anmeldung im Portal zu verwendende Authentication-Schema fest. pab Vollständiger Pfad und Dateiname für das Private Address Book (PAB) mit den öffentlichen Schlüsselzertifikaten der als vertrauenswürdig eingestuften Herausgeber von Tickets. Jedem unter trustedissuer aufgelisteten Herausgeber von Tickets sollte auch ein entsprechendes X.509-Zertifikat zugewiesen sein. Auf diese Weise erhalten Sie ein hochgradig anpassbares und wiederverwendbares Login-Modul, das auch für andere, noch nicht in das Portal integrierte Anwendungen eingesetzt werden kann, vorausgesetzt sie laufen auf einem JAAS-konformen Container. Anwendungsintegration über Filter Die Frage, wie das Login-Modul von den bestehenden Anwendungen möglichst ohne Änderungen aufgerufen und integriert werden kann, blieb bislang noch ungeklärt. Da der Quellcode der Servlets und JSPs nicht verändert werden darf, fällt Ihre Wahl schließlich auf die Erstellung eines Servlet-Filters (siehe Kasten Servlet-Filter), der den Anwendungen im Deployment Descriptor web.xml vorgeschaltet werden kann, um eine entsprechende Authentifizierung der eingehenden Requests vor dem eigentlichen Aufruf der Servlets oder JSPs durchzuführen. 174

13 Single Sign-on im Intranet 4.2 Servlet-Filter Ab der J2EE-Servlet-Spezifikation 2.3 besteht die Möglichkeit, mit den sogenannten Servlet-Filtern auf der konzeptionellen Grundlage des Entwurfsmusters J2EE Decorating Filter ( DecoratingFilter.html) anwendungsübergreifende und wiederverwendbare Prä- bzw. Postprozessoren für den HTTP Request bzw. die HTTP Response zu implementieren. Typische Anwendungsfälle für Servlet-Filter sind Querschnittsfunktionen (Crosscutting Concerns), die nicht die Kernfunktionalität von Anwendungen betreffen. Dazu zählen: Protokollierung (Logging) von bestimmten Zugriffen oder Ereignissen Komprimierung von Daten zur schnelleren Übertragung Aufzeichnung der Verarbeitungsdauer zwischen dem einkommenden Request und der ausgehenden Response zur Messung der Performance Authentifizierung von Requests und weitere Sicherheitsdienste (z.b. Verschlüsselung bzw. Entschlüsselung bestimmter Daten) Servlet-Filter lassen sich deklaratorisch über den web.xml-deployment Descriptor in die Verarbeitungskette des Requests einer Anwendung einbinden, um auf dieses Weise dessen Inhalt zu prüfen und eventuell Modifikationen im Sinne eines Präprozessors durchzuführen. Gleiches gilt für die Response, die ebenfalls vom Filter vor der Auslieferung an den Browser noch nachträglich manipuliert werden kann. Servlet-Filter haben den besonderen Vorteil, dass ihre zusätzliche Funktionalität außerhalb des Quellcodes der sie betreffenden Anwendungen implementiert wird. Sie lassen sich getrennt von den Anwendungen verwalten und dynamisch hinzufügen bzw. wieder entfernen. Jeder Servlet Filter muss dass Java Interface javax.servlet.filter implementieren, das mit drei Methoden den gesamten Lebenszyklus eines Filters definiert: init(filterconfig config) Nimmt die Initialisierung des Filters vor, mit deren Hilfe filterspezifische Konfigurationsparameter über das FilterConfig-Objekt gesetzt werden können. dofilter(servletrequest req, ServletResponse res, Filter- Chain chain) Hier findet die eigentliche Arbeit des Filters mit dem Request (req) bzw. der Response (res) statt. Nach Ausführung der Präprozessor- Tätigkeiten auf dem req-objekt muss mit chain.dofilter(req, res) die Weiterleitung des Requests in der Verarbeitungskette, die über das Interface FilterChain definiert und vom Webcontainer implementiert wird, durch eventuell noch folgende Filter sichergestellt werden. Wenn die Methode chain.dofilter zurückkehrt, kann der Filter bei Bedarf das Response-Objekt noch nachträglich modifizieren. 175

14 4 Single Sign-on destroy() Dient zur Erledigung von Aufräumarbeiten, wenn der Filter aus dem Webcontainer entfernt werden soll, und wird wie init nur einmal im Lebenszyklus aufgerufen. Mit der Integration von AddressBook in das neue Mitarbeiterportal soll der Anmeldeprozess zukünftig wie in Abbildung 4.2 dargestellt ablaufen: Abbildung 4.2 SSO-Integration von externen Anwendungen im Mitarbeiterportal über das SAP Logon Ticket Anmeldeprozess Schritt 1 Der Mitarbeiter meldet sich am Portal mit seinem Benutzernamen und Passwort an. Schritt 2 Nach erfolgreicher Authentifizierung wird dem Mitarbeiter vom Portal ein SAP Logon Ticket mit dem DNS-Domainnamen portal.securesale.com ausgestellt, das innerhalb der Intranet- Domäne securesale.com für die Dauer seiner Gültigkeit (standardmäßig acht Stunden) für den Single Sign-on verwendet werden kann. 176

15 Single Sign-on im Intranet 4.2 Schritt 3 Innerhalb der Portalseiten werden über URL-iViews die Anwendungen auf den entfernten Systemen eingebunden. Der Browser beim Mitarbeiter richtet also den HTTP Request zur Anzeige des Inhalts des iview nicht an den Portal-Server, sondern an andere Systeme im Intranet, im Falle der AddressBook-Anwendung an das System mit dem DNS-Domainnamen tomcat.securesale.com. Da sich tomcat.securesale.com in der gleichen Domäne wie portal.securesale.com befindet, schickt der Browser das in Schritt 2 erhaltene Ticket ebenfalls mit. Schritt 4 Der Servlet Filter SLTAuthenticationFilter ist über die Konfiguration im Deployment Descriptor web.xml der AddressBook- Anwendung in die Verarbeitungskette eingebunden. Listing 4.1 zeigt den entsprechenden Ausschnitt aus der Datei. <web-app>... <filter> <filter-name>sltauthenticationfilter</filter-name> <filter-class> com.securesale.slt.sltauthenticationfilter </filter-class> </filter> <filter-mapping> <filter-name>sltauthenticationfilter</filter-name> <url-pattern>/addressbooksearch</url-pattern> </filter-mapping> <filter-mapping> <filter-name>sltauthenticationfilter</filter-name> <url-pattern>/search.jsp</url-pattern> </filter-mapping>... </web-app> Listing 4.1 Konfiguration des Servlet-Filters SLTAuthenticationFilter im Deployment Descriptor web.xml der AddressBook-Anwendung Im Element <filter> wird unter <filter-class> der vollständige Paket- und Klassenname des Filters angegeben, der mit einem eindeutigen Konfigurationsnamen (SLTAuthenticationFilter) im Element <filter-name> verknüpft wird. Anschließend können über URL-Patterns in Form von <filter-mapping> Einträgen die Filter- Konfiguration 177

16 4 Single Sign-on Servlets oder JSPs angegeben werden, bei denen der Filter aktiviert werden soll. Für die AddressBook-Anwendung sind das die Suchseite (/search.jsp) sowie das durch sie aufgerufene Servlet (/AddressBookSearch), das die eigentliche Suche durchführt. Folglich können Requests diese beiden Komponenten nur dann ungehindert passieren, wenn sie ein gültiges Ticket mit sich führen. Die entsprechende Implementierung der dofilter-methode in der SLTAuthenticationFilter-Klasse finden Sie in Listing 4.2. public void dofilter(servletrequest request, ServletResponse response, FilterChain filterchain) throws IOException, ServletException {... if (request instanceof HttpServletRequest) { // search for the SAP Logon Ticket in the request HttpServletRequest req = (HttpServletRequest) request; HttpSession session = req.getsession(true); Subject subject = (Subject)session.getAttribute( "javax.security.auth.subject"); if (subject == null) { subject = new Subject(); } session.setattribute("javax.security.auth.subject", subject); // pass request with ticket to the SLT login module try { LoginContext lc = new LoginContext("addressBook", subject, new SLTCallbackHandler(req)); lc.login(); } catch (LoginException le) { // Access failed - return HTTP Status 403 HttpServletResponse res = (HttpServletResponse) response; res.senderror(httpservletresponse.sc_forbidden, "Unauthorized Access: No valid SSO Ticket found"); return; } } else logger.debug("sltauthenticationfilter only accepts HTTP Requests!"); 178

17 Single Sign-on im Intranet 4.2 } filterchain.dofilter(request, response); Listing 4.2 Implementierung der dofilter-methode im SLTAuthenticationFilter Um nicht mit jedem eingehenden Request auch ein neues Subject zu erzeugen, wird zunächst in der HTTP Session (session) unter dem Attributnamen javax.security.auth.subject nach einem bereits existierenden Objekt gesucht. Nur wenn dort noch nichts abgelegt ist, wird ein neues Subject erstellt und in die Session geschrieben. Caching des Subjects Die eigentliche Überprüfung delegiert der Filter anschließend an das JAAS Login Module SLTLoginModule, das er über die aus Abschnitt schon bekannte JAAS API mit new LoginContext("addressBook", subject, new SLTCallbackHandler(req)) initialisiert. Der erste Parameter ("addressbook") bezieht sich auf den Namen des Login-Modul-Stacks, dessen Konfiguration bei Tomcat in einer einfachen Textdatei ausgelagert und beim Start des Webcontainers über das Java-VM-Argument -Djava.security.auth.login.config=<Pfad und Dateinamen auf JAAS Konfigurationsdatei> angegeben wird. Listing 4.3 zeigt den Inhalt der Datei jaas.config, in der die Konfiguration zum Login-Modul-Stack addressbook enthalten ist. Dieser enthält in diesem Fall nur einen einzigen Eintrag, das SLTLoginModule, dem das Module Flag required zugewiesen ist. Auf die einzelnen Modul-Optionen wird im Folgenden Bezug genommen. addressbook { com.securesale.slt.sltloginmodule required authschema="basicauthentication" trustedissuer="cn=employee Portal, O=SecureSale Inc." pab="c:\\tmp\\tomcat.pse" pabpwd="secret"; }; Listing 4.3 Inhalt der Tomcat-JAAS-Konfigurationsdatei für das Unternehmensszenario Schritt 5 Das Login-Modul muss sich zunächst das Ticket aus dem Request besorgen. Dazu verwendet es den eigenen Callback Handler SLT- Callback Handler CallbackHandler, der ebenfalls beim Erzeugen des LoginContext im vorherigen Schritt übergeben wurde. STLCallbackHandler kann nur mit einem HTTPServletRequest-Objekt instanziert wer- 179

18 4 Single Sign-on den. Der Grund dafür liegt nahe: Der Callback Handler benötigt den aktuellen HTTP-Request, um dort nach dem Cookie mit dem Namen MYSAPSSO2 zu suchen. Listing 4.4 zeigt die Implementierung der Methode login() aus dem SLTLoginModule. Hier wird auf dem Callback Handler die Methode handle(new Callback[] {nc}) aufgerufen, über die das SAP Logon Ticket im Request gesucht wird. public boolean login() throws LoginException { // check if callback handler is available if (callbackhandler == null) { throw new LoginException(); } // retrieve SAP Logon Ticket from handler and verify it try { // use NameCallback to retrieve SLT value NameCallback nc = new NameCallback("ticket"); callbackhandler.handle(new Callback[] {nc}); if (nc.getname()!= null) this.authuser = verifyslt(nc.getname()); else throw new LoginException(); succeeded = true; } catch (Exception e) { throw new LoginException(); } return succeeded; } Listing 4.4 login-methode im SLTLoginModule NameCallback als Zwischenspeicher Mithilfe des zum Standardumfang der JAAS API gehörenden Callbacks javax.security.auth.callback.namecallback wird das Ticket vom Callback Handler in der NameCallback-Instanz nc zwischengespeichert. Verläuft die Suche erfolgreich, steht das Ticket über nc.getname() im Login-Modul für die eigentliche Überprüfung (Schritt 7) bereit. Doch lohnt sich vorab noch ein tieferer Blick in die Arbeitsweise des Callback Handlers. Schritt 6 Da der HTTP Request bei der Initialisierung des Callback Handlers übergeben und eine Callback-Instanz vom Typ NameCallback im Login-Modul erzeugt wurde, kann nun die vom SLTCallbackHand- 180

19 Single Sign-on im Intranet 4.2 ler implementierte handle()-methode des JAAS-Interface CallbackHandler ihre Arbeit aufnehmen (siehe Listing 4.5): public void handle(callback[] callbacks) throws IOException, UnsupportedCallbackException { NameCallback nc = null; for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) { nc = (NameCallback) callbacks[i]; } else throw new UnsupportedCallbackException(callbacks[i], "SLTCallbackHandler"); } // extract SAP Logon Ticket from request Cookie[] cookies = request.getcookies(); if (cookies!= null) { String sltcookiename = "MYSAPSSO2"; Cookie slt = null; for (int i = 0; i < cookies.length; i++) { Cookie cookie = cookies[i]; if (sltcookiename.equals(cookie.getname()) && slt == null) slt = cookie; } if (slt!= null) { if (nc!= null) { nc.setname(slt.getvalue()); } } } } Listing 4.5 handle()-methode im SLTCallbackHandler Zunächst wird die vom Login-Modul übergebene NameCallback- Instanz (nc) aus dem callbacks-array gelesen. Die anschließende Suche nach dem SAP Logon Ticket erweist sich als unproblematisch: Mit request.getcookies() erhält man ein Array aller im Request enthaltenen Cookies, das anschließend Eintrag für Eintrag durchsucht wird, wobei der jeweilige Name (cookie.getname()) mit der Bezeichnung MYSAPSSO2 für das SAP Logon Ticket verglichen wird. Trifft der Callback Handler auf das gesuchte Cookie, so scheibt er dessen Wert im NameCallback-Objekt mit nc.set- Name(slt.getValue()) fest. 181

20 4 Single Sign-on Verwendung von SAPSSOEXT Schritt 7 Nun ist das SLTLoginModule in der Lage, das Ticket mit der externen Bibliothek SAPSSOEXT zu überprüfen. Sie verifiziert die Signatur des Tickets und liefert dessen Inhalt, beispielsweise den Benutzernamen, das verwendete Authentication Template bei der Portalanmeldung oder den Namen seines Herausgebers. Die verwendete Wrapper-Klasse SSO2Ticket für die Aufrufe der von SAPSSOEXT bereitgestellten Funktionen ist in Listing 4.6 dargestellt. package com.mysap.sso; public class SSO2Ticket { public static String SECLIBRARY; public static String SSO2TICKETLIBRARY = "sapssoext"; static { if (System.getProperty("os.name").startsWith("Win")){ SECLIBRARY = "sapsecu.dll"; } else { SECLIBRARY = "libsapsecu.so"; } try { System.loadLibrary(SSO2TICKETLIBRARY); } catch (Throwable e) { logger.error("error during initialization of SSO2Ticket: " + e.getmessage()); } } public static native synchronized boolean init(string seclib); public static native synchronized String getversion(); public static native synchronized Object[] evallogonticket(string ticket, String pab, String pab_password) throws Exception; public static native synchronized String parsecertificate(byte[] cert, int info_id); } Listing 4.6 Java-Wrapper-Klasse SSO2Ticket für die SAPSSOEXT-Bibliothek SSO2Ticket entspricht weitestgehend der Beispieldatei, die mit dem Download der SAPSSOEXT-Bibliothek vom SAP Service Marketplace ausgeliefert wird. Allerdings wurde der Wrapper-Klasse 182

21 Single Sign-on im Intranet 4.2 ihre Paket-Definition com.mysap.sso hinzugefügt, die mit der Bennungen der Funktionen in der Bibliothek übereinstimmt (siehe Kasten Java Native Interface und SAPSSOEXT). Java Native Interface und SAPSSOEXT Für die Einbindung von betriebssystemspezifischen Funktionen oder Methoden in Java, die in einer anderen Programmiersprache wie z.b. C oder C++ entwickelt wurden, stellt das Java Native Interface (JNI) eine standardisierte API zur Verfügung. Zunächst müssen alle Methoden der externen Bibliothek als betriebssystemspezifische Methoden über das Schlüsselwort native in einer Java- Klasse deklariert werden, die später als sogenanntes Wrapper-Objekt für die eigentliche Weiterleitung der Aufrufe an die nativen Bibliotheksfunktionen dient. Damit die Bibliothek auch zur Laufzeit in den Speicher der Java Virtual Machine (VM) geladen wird, empfiehlt sich im statischen Initialisierungsblock der Klasse der Aufruf von System.loadLibrary( "<Bibliotheksname>"). Da sich der static-block wie ein Konstruktor für die Klasse verhält, wird dieser Code auch nur einmal ausgeführt, und zwar beim Laden der Klasse durch den Classloader der VM. Die C/C++-Bibliothek muss sich an bestimmte Namenskonventionen halten, um über JNI einem Java-Programm ihre Dienste als dynamisch ladbare Bibliothek auf der jeweiligen Plattform (z.b. als Dynamic Link Library unter Windows) anbieten zu können. Die Methodennamen in der Bibliothek dürfen nicht einfach den Methodennamen aus der Java-Klasse übernehmen, sondern müssen das Präfix Java tragen, gefolgt von dem vollständigen Paket- und Klassennamen, schließlich dem Methodennamen selbst. Die einzelnen Paketglieder werden mit einem Unterstrich kenntlich gemacht, sodass z.b. aus der als nativ deklarierten Java-Methode invent() in der Klasse Inventor aus dem Paket org.genius die C/C++- Bibliotheksfunktion Java_org_genius_Inventor_invent wird. Die Funktionsnamen der SAPSSOEXT-Bibliothek sind ebenfalls an einen festen Paket- und Klassennamen gebunden. Die Methode evallogon- Ticket zur Überprüfung der Gültigkeit des Tickets ist beispielsweise unter dem Namen Java_com_mysap_sso_SSO2Ticket_evalLogonTicket registriert. Daraus lässt sich ableiten, dass der Klassenname des Wrapper- Objekts SSO2Ticket und der Name seines Pakets com.mysap.sso lauten muss. Befolgt man diese Vorgaben nicht, erhält man bei Aufruf der Bibliotheksfunktionen über die nativen Methoden der Java-Klasse eine Exception vom Typ java.lang.unsatisfiedlinkerror, die mitteilt, das die VM nicht in der Lage war, die gewünschte Methode in der Bibliothek ausfindig zu machen. 183

22 4 Single Sign-on Von zentralem Interesse in SSO2Ticket ist die Prüffunktion eval- LogonTicket, deren Verwendung Listing 4.7 am Beispiel der Methode verifyslt im SLTLoginModule zeigt. private User verifyslt(string ticketvalue) throws LoginException { try { // initialize library if (!SSO2Ticket.init(SSO2Ticket.SECLIBRARY)) { return null; } Object o[] = SSO2Ticket.evalLogonTicket(ticketValue, options.getproperty(option_param_pab), options.getproperty(option_param_pabpwd)); // check if the issuer is trused String ticketissuer = SSO2Ticket.parseCertificate( (byte[]) o[3], ISSUER_CERT_ISSUER); if (!ticketissuer.equals( options.getproperty(option_param_trustedissuer))) { throw new LoginException(); } else // create new user principal User user = new User(); user.setname((string) o[0]); return user; } catch (Exception e) { throw new LoginException("Could not verify the SAP Logon Ticket"); } } Listing 4.7 Methode verifyslt im Login-Modul zur Überprüfung des SAP Logon Tickets Vor der erstmaligen Überprüfung eines Tickets muss die Bibliothek zunächst über SSO2Ticket.init mit einem Verweis auf die zu verwendende Kryptobibliothek (SSO2Ticket.SECLIBRARY) initialisiert werden. Anschließend liefert SSO2Ticket.evalLogonTicket alle benötigten Daten aus dem in ticketvalue übergebenen Wert des MYSAPSSO2-Cookies zurück, sofern folgende Voraussetzungen erfüllt sind: Voraussetzungen Das zur Überprüfung der Signatur benötigte Zertifikat muss im Private Address Book (PAB) vorhanden sein, dessen vollständi- 184

23 Single Sign-on im Intranet 4.2 ger Pfad- und Dateiname als Option pab in der Konfiguration des Login-Moduls (siehe Listing 4.3) angegeben wird. Der Zugriff auf das PAB muss durch das ebenfalls in der Login- Module-Konfiguration angegebene Passwort (Option pabpwd) möglich sein. Das Ticket muss gültig sein, d.h., die im Ticket abgelegten Daten müssen authentisch sein und der im Ticket angegebene Gültigkeitszeitraum darf nicht überschritten worden sein. Das Array o[] beinhaltet bei erfolgreicher Rückkehr der Funktion den strukturierten Inhalt des Tickets. So enthält Index-Position Nummer drei (o[3]) das Zertifikat des Ausstellers als Byte-Array, das über SSO2Ticket.parseCertificate weiter in seine Einzelinformationen zerlegt werden kann. Auf diese Weise lässt sich z.b. der Distinguished Name (DN) des Herausgebers ermitteln und mit dem als vertrauenswürdig eingestuften Namen aus der Login- Modul-Konfigurationsdatei jaas.config (siehe Listing 4.3) vergleichen. Verlaufen auch die zusätzlichen Prüfungen ohne Beanstandungen, kann im letzten Schritt das Benutzerobjekt mit dem Namen des im Ticket übermittelten Subjects (user.setname((string)o[0])) erzeugt werden. Auf die Überprüfung der Existenz des Benutzers in einer lokalen Benutzerverwaltung wird verzichtet, da es jedem Mitarbeiter, der sich ordnungsgemäß über das Portal angemeldet hat, gestattet sein soll, auch das Adressbuch zu nutzen. Schritt 8 Fällt die Authentifizierungsentscheidung positiv aus, kehrt der Aufruf des Login-Modul-Stacks ohne eine LoginException zurück, und der Request wird an die Verarbeitungskette mit filter- Chain.doFilter(request, response) (siehe Listing 4.2) den weiteren Filtern übergeben Schritt 9 Nach Beendigung der Filter-Verarbeitungskette und Verarbeitung des Requests in der AddressBook-Anwendung liefert der SLT- AuthenticationFilter die Response unverändert an den Browser aus. Sie finden den vollständigen Quellcode zur AddressBook-Anwendung inklusive dem Servlet-Filter im Übungsverzeichnis /exercise3_ solution. 185

24 4 Single Sign-on Vertrauensverhältnis Unerlässlich für eine positive Verifizierung des Tickets ist die Etablierung eines Vertrauensverhältnisses auf der Basis einer PKI zwischen der AddressBook-Anwendung und dem Mitarbeiterportal. Dazu ist es notwendig, das Zertifikat mit dem öffentlichen Schlüssel des im Portal für Ticketsignaturen verwendeten Schlüsselpaars dem externen System bekannt zu machen. Wie in Schritt 7 beschrieben, muss dieses Zertifikat über ein sicheres Medium ausgetauscht werden und der dezentral installierten SAPSSOEXT-Bibliothek in Form einer PAB-Datei vorliegen. Diese und weitere Schritte werden in der folgenden Übung beschrieben, die das Szenario in die Praxis umsetzt Übung 3: SSO-Integration von AddressBook in das Mitarbeiterportal In dieser Übung wird die Anwendung AddressBook, wie in Abbildung 4.2 gezeigt, in das SAP NetWeaver Portal integriert. Um die Übung überschaubar zu halten, werden die Einzelschritte zur Erstellung der eigentlichen Anwendung nicht betrachtet; stattdessen wird mit einer bereits fertigen Implementierung gearbeitet. Die folgenden Schritte konzentrieren sich maßgeblich auf die Konfigurationen im Mitarbeiterportal sowie die Integration der SAP-Logon-Ticket-Bibliothek auf dem Apache Tomcat Server. Installation des Apache Tomcat Servers Simulation auf einem Rechner Obwohl das Szenario von zwei separaten Rechnern mit eigenen Domainnamen ausgeht, kann diese Übung auch auf einem Rechner durchgeführt werden. In den folgenden Schritten wird davon ausgegangen, dass die Installation der Ablaufumgebung für die Address- Book-Anwendung, der Apache Tomcat Server, auf demselben System erfolgt, auf dem bereits der AS Java (SAP NetWeaver 7.0) für das Mitarbeiterportal läuft. Um dennoch das Szenario mit zwei unterschiedlichen Domainnamen zu simulieren, fügen Sie bitte die beiden Einträge aus Listing 4.8 der lokalen hosts-datei im Windows-Systemordner C:\WINDOWS\system32\drivers\etc hinzu. Die hosts-datei dient der Zuordnung von Hostnamen und IP-Adressen. 186

25 Single Sign-on im Intranet portal.securesale.com tomcat.securesale.com Listing 4.8 Hostnamen in der hosts-datei zur Simulation des AddressBook- Szenarios auf einem Rechner 1. Laden Sie zunächst die aktuelle Version 5.5.x von Tomcat für Ihre Systemplattform von herunter. Es genügt die binäre Core Distribution ohne den Quellcode, die als ZIP-Archiv vorliegt. Des Weiteren benötigen Sie für dieses Tomcat-Release und die AddressBook-Anwendung ein Java Runtime Environment (JRE) 5.0, das bei Bedarf von downloads/index_jdk5.jsp bezogen werden kann. Tomcat 5.5 und JRE Die Installation von Tomcat ist schnell geschehen: Entpacken Sie das heruntergeladene ZIP-Archiv im gewünschten Zielverzeichnis, von dem aus Sie den Webcontainer starten wollen, z.b. in C:\ Program Files. Dort finden Sie nun ein neues Verzeichnis mit dem Namen apache-tomcat-5.5.x. 3. Um später den sicheren Transport der SAP Logon Tickets zum Webcontainer zu gewährleisten, müssen Sie noch den SSL Connector im Apache Tomcat aktivieren. Öffnen Sie dazu im Ordner apache-tomcat-5.5.x/conf die zentrale Konfigurationsdatei server.xml. SSL in Tomcat aktivieren 4. Suchen Sie die in Listing 4.9 angegebene Stelle in der Datei und entfernen Sie die Kommentarzeichen (<!-- und -->), die das Element <Connector> umschließen. Ergänzen Sie anschließend die fett markierten Einträge, mit denen der vom SSL Connector zu verwendende Schlüssel angegeben wird.... <!-- Define a SSL HTTP/1.1 Connector on port > <Connector port="8443" maxhttpheadersize="8192" maxthreads="150" minsparethreads="25" maxsparethreads="75" enablelookups="false" disableuploadtimeout="true" acceptcount="100" scheme="https" secure="true" clientauth="false" sslprotocol="tls" keyalias="tomcatssl" keystorefile="c:\\program Files\\apache-tomcat \\conf\\tomcat.jks" keystorepass="secret" />... Listing 4.9 SSL-Einstellungen in der Apache-Tomcat-server.xml-Konfigurationsdatei 187

26 4 Single Sign-on 5. Stellen Sie nun noch die folgenden Voraussetzungen für einen reibungslosen Betrieb des SSL-Connectors im Apache Tomcat sicher: Der Java Keystore tomcat.jks ist mit einem gültigen und von einer vertrauenswürdigen Zertifizierungsstelle beglaubigten SSL-Zertifikat im angegebenen Verzeichnis von keystorefile vorhanden und kann mit dem in keystorepass angegebenen Passwort ausgelesen werden. Verwenden Sie dazu entweder die bereits vorbereitete Datei tomcat.jks aus dem Ordner keys/ssl/securesale/tomcat/ des Übungsarchivs, oder folgen Sie den Schritten in Anhang A.2, um die Keystore-Datei und das SSL-Zertifikat selbst zu erstellen. Das Wurzelzertifikat der im Unternehmensszenario eingesetzten Zertifizierungsstelle TrustedCA ist in den Zertifikatsspeicher des lokalen Rechners für vertrauenswürdige Wurzelzertifikate importiert. Folgen Sie dazu der Beschreibung in Anhang A.1.3. Sie können das bereits erstellte Wurzelzertifikat mit dem Dateinamen CA_Cert.crt aus dem Ordner /keys/ca des Übungsarchivs für den Import verwenden. Anschließend akzeptiert die Apache-Tomcat-Instanz auf dem TCP/IP-Port 8443 eingehende SSL-Verbindungen. Test der Tomcat- Installation 6. Sie können den Webcontainer für einen ersten Test starten, indem Sie in das Unterverzeichnis /bin wechseln und dort die Batch-Datei startup.bat (Windows) bzw. das Shell-Script startup.sh (Unix) ausführen. Stellen Sie dabei sicher, dass die Umgebungsvariable JRE_ HOME auf das Hauptverzeichnis Ihrer Java 5.0-Laufzeitumgebung verweist (z.b. C:\Program Files\Java\jre1.5.0_02). 7. Gehen Sie anschließend mit einem Browser auf die Tomcat-Startseite, die Sie nun unter index.jsp, wie in Abbildung 4.3 dargestellt, über SSL erreichen sollten. 188