Single Sign-on mit SAP

Transkript

1 Martijn de Boer, Mathias Essenpreis, Stefanie García Laule, Martin Raepple Single Sign-on mit SAP Lösungen für die Praxis Bonn Boston

2 Auf einen Blick TEIL I Grundlagen 1 Grundlegende Begriffe und Konzepte Single-Sign-on-Technologien und -Standards TEIL II Single Sign-on für Benutzerschnittstellen 3 Workshop: Single Sign-on mit Kerberos für SAP GUI Workshops: Browser-Single-Sign-on mit Zertifikaten Workshop: Single Sign-on mit SPNEGO Workshops: Single Sign-on für Webanwendungen mit SAML Workshop: OpenID mit einem externen Portal TEIL III Single Sign-on mit Webservices 8 Workshops: Single Sign-on zum AS ABAP als WS-Provider Workshop: Single Sign-on in SAP NetWeaver BPM Anhang A Fehleranalyse für die SAML- und X.509-Authentifizierung B Literatur und weiterführende Websites C Die Autoren

3 Inhalt Vorwort Einleitung TEIL I Grundlagen 1 Grundlegende Begriffe und Konzepte SSO und verwandte Konzepte Chancen und Risiken Terminologie Security Assertion Identity Provider Security Token Service Service Provider Technische und organisatorische Anforderungen SSO im Unternehmen SSO zwischen Unternehmen Identitätsverwaltung Single-Sign-on-Technologien und -Standards Konzepte im SAP-Umfeld Digitale Signatur und Zertifikate SAP Logon Ticket SAML für Web-Single-Sign-on SAML für Webservices Kerberos OpenID Vergleich der SSO-Technologien Single-Sign-on-Szenarien mit SAP NetWeaver TEIL II Single-Sign-on für Benutzerschnittstellen 3 Workshop: Single Sign-on mit Kerberos für SAP GUI Einführung in das Szenario Systemvoraussetzungen Konfiguration und Test des Szenarios

4 Inhalt 3.4 Wichtige SAP-Hinweise Zusammenfassung Workshops: Browser-Single-Sign-on mit Zertifikaten Workshop: Active Directory Certificate Services Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte Szenario testen Fehleranalyse und -behebung Wichtige SAP-Hinweise Zusammenfassung Workshop: SAP Trust Center Service Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte Zusammenfassung Workshop: Single Sign-on mit SPNEGO Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte Servicebenutzer in der Domäne erstellen SPN zuordnen Benutzerspezifisches UME-Attribut für den Kerberos Prinicpal Name hinzufügen Kerberos-Konfiguration für neuen Realm im Portal anlegen Authentication Stack im Portal für SPNEGO konfigurieren Domänen- und Portalbenutzer anlegen Szenario testen Fehleranalyse und -behebung Wichtige SAP-Hinweise Zusammenfassung Workshops: Single Sign-on für Webanwendungen mit SAML Workshop: Web-SSO zwischen Unternehmen Einführung in das Szenario

5 Inhalt Systemvoraussetzungen Konfigurationsschritte Szenario testen Fehleranalyse und -behebung Wichtige SAP-Hinweise Zusammenfassung Workshop: Web-SSO in einer heterogenen Systemlandschaft Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte Szenario testen Fehleranalyse und -behebung Wichtige SAP-Hinweise Zusammenfassung Workshop: OpenID mit einem externen Portal Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte OpenID-URL registrieren OpenID-Komponenten im Portal installieren Neue OpenID-Anmeldeanwendung aktivieren UME-Attribut für OpenID-URL anlegen Authentication Stack für OpenID konfigurieren Szenario testen Fehleranalyse und -behebung Wichtige SAP-Hinweise Zusammenfassung TEIL III Single-Sign-on mit Webservices 8 Workshops: Single Sign-on zum AS ABAP als WS-Provider Einführung Single Sign-on zwischen einer Serveranwendung und AS ABAP mit SAML-Sender-Vouches Konfiguration des WS-Providers für SAML-Sender- Vouches Konfiguration des WS-Providers

6 Inhalt Selbst signierten Signaturschlüssel für den WS-Consumer erzeugen Vertrauensbeziehung einrichten Workshop: Single Sign-on mit Apache Axis2 und Apache Rampart Single Sign-on mit SAML 1.1-Sender-Vouches Konfiguration des WS-Providers WS-Consumer erstellen WS-Consumer konfigurieren Webservice aufrufen Vertrauensbeziehung einrichten Szenario testen Fehleranalyse und -behebung Workshop: Single Sign-on mit Sun Metro Single Sign-on mit SAML 1.1-Sender-Vouches WS-Provider konfigurieren WS-Consumer erstellen WS-Consumer konfigurieren Webservice aufrufen Vertrauensbeziehung einrichten Szenario testen Fehleranalyse und -behebung Workshop: Single Sign-on mit anderen EE5-Plattformen Single Sign-on mit SAML 1.1-Sender-Vouches WS-Provider konfigurieren WS-Consumer erstellen WS-Consumer konfigurieren Vertrauensbeziehung einrichten Szenario testen Fehleranalyse und -behebung Workshop: Single Sign-on mit einer.net-serveranwendung Single Sign-on mit SAML 1.1-Sender-Vouches WS-Provider konfigurieren WS-Consumer erstellen WS-Consumer konfigurieren Vertrauensbeziehung einrichten Szenario testen Fehleranalyse und -behebung Single Sign-on zwischen Desktop-Anwendungen und dem AS ABAP Authentifizierung mit SAML-Holder-of-Key

7 Inhalt Einführung in das Szenario Authentifizierung mit X.509-Zertifikaten Workshop: Single Sign-on mit X.509-Zertifikaten zwischen einer Java-Desktop-Anwendung mit Sun Metro und AS ABAP Provider-Konfiguration anlegen Vertrauensbeziehung einrichten Benutzerabbildung über den Report RSUSREXT WS-Consumer erstellen WS-Consumer konfigurieren Szenario testen Fehleranalyse und -behebung Workshop: Single Sign-on zwischen Microsoft Office und dem AS ABAP Single Sign-on mit SAML 1.1-Holder-of-Key Systemvoraussetzungen ADFS-Security-Token-Service konfigurieren Relying Partys mit AS ABAP 7.02 und 7.30 konfigurieren Relying Partys mit AS ABAP 7.01 und 7.11 konfigurieren Auszustellende Claims konfigurieren Vertrauensbeziehung im SAP-WS-Provider-System einrichten WS-Provider konfigurieren WS-Consumer erstellen WS-Consumer konfigurieren Szenario testen Fehleranalyse und -behebung Zusammenfassung Workshop: Single Sign-on in SAP NetWeaver BPM Einführung in das Szenario Systemvoraussetzungen Konfigurationsschritte Voraussetzungen für die Konfiguration des Szenarios Benutzer für das Szenario anlegen SAP NetWeaver Developer Studio vorbereiten BPM-Prozess für Single Sign-on konfigurieren Nachrichtenbasierte Authentifizierung einrichten

8 Inhalt Vertrauensbeziehung zwischen WS-Provider und WS-Consumer einrichten WS-Provider für Single Sign-on konfigurieren WS-Consumer für Single Sign-on konfigurieren Abbildungsinformationen des Benutzernamens auf dem SAP ERP-System pflegen Szenario testen Fehleranalyse und -behebung Fehlersuche im AS Java Fehlersuche im AS ABAP Wichtige SAP-Hinweise Zusammenfassung Anhang A Fehleranalyse für die SAML- und X.509-Authentifizierung B Literatur und weiterführende Websites C Die Autoren Index

9 Ein wenig Theorie muss sein: Kurz und bündig erfahren Sie in diesem Kapitel, welche Technologien für Single Sign-on mit SAP eine wichtige Rolle spielen und welche Standards unterstützt werden, um auch Fremdsysteme zu integrieren. 2 Single-Sign-on-Technologien und -Standards Mit der Kommerzialisierung des World Wide Webs (WWW) Mitte der neunziger Jahre und dem damit einhergehenden Anstieg zugangsgeschützter Websites wurde der Ruf nach Lösungen laut, die der Flut von Benutzernamen und Passwörtern Einhalt gebieten können. Schnell wurde mit ersten Lösungsvorschlägen wie mit dem 1999 eingeführten.net Passport reagiert, mit dem sein Betreiber Microsoft leidgeprüften Internetanwendern einen zentralen Anmeldedienst zur Verfügung stellte. Einmal auf der Passport-Seite registriert, erfolgte die Anmeldung bei Microsofts eigenen Online-Diensten wie Hotmail oder dem Messenger automatisch und ohne erneute Passworteingabe. Dieses Single-Sign-on-System konnte jedoch nie eine nennenswerte Verbreitung unter Anwendern und Anbietern von geschützten Internetdiensten verzeichnen. Konkurrenz bekam.net Passport etwas später durch die Liberty Alliance: Der im Jahr 2001 von Sun Microsystems gegründete Verbund machte sich die Entwicklung offener Standards für ein dezentral organisiertes Single-Sign-on-System zur Aufgabe und bot damit aus organisatorischer und technologischer Sicht einen Gegenvorschlag zu.net Passport. Obwohl die von der Liberty Alliance verabschiedeten Konzepte nicht für einen weltweiten Anmeldedienst im Internet eingesetzt wurden, beeinflussten viele der dort entstandenen Ideen die Entwicklung eines wichtigen Standards für SSO in Unternehmen und zwischen Geschäftspartnern: die Security Assertion Markup Language (SAML). SAML gesellt sich zu einer Reihe weiterer Technologien wie digitale Zertifikate, Kerberos und OpenID, die ebenfalls im SAP-Umfeld für SSO von Bedeutung sind und im folgenden Abschnitt genauer betrachtet werden. 35

10 2 Single-Sign-on-Technologien und -Standards 2.1 Konzepte im SAP-Umfeld Den von SAP unterstützten Technologien und Standards für Single Sign-on liegen unterschiedliche Ansätze zugrunde Digitale Signatur und Zertifikate Betrachten wir zunächst die digitale Signatur, die in vielen nationalen und internationalen Gesetzesregelungen grundsätzlich mit der klassischen papiergebundenen Unterschrift juristisch gleichgestellt wird. Zur Erstellung einer digitalen Signatur kann die asymmetrische Verschlüsselung eingesetzt werden. Dabei kommen zwei komplementäre, aber miteinander in Beziehung stehende Schlüssel zum Einsatz. Das Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel (Private und Public Key), ist so entworfen, dass mit dem öffentlichen Schlüssel verschlüsselte Daten nur mit dem passenden privaten Schlüssel entschlüsselt werden können (und umgekehrt: nur mit dem richtigen privaten Schlüssel chiffrierte Informationen können auch von Empfängern, die im Besitz des zugehörigen öffentlichen Schlüssels sind, dechiffriert werden). Abbildung 2.1 zeigt, dass der Sender zur Erstellung einer digitalen Signatur auf die betreffende Nachricht zunächst eine Hash-Funktion anwendet 1, deren Ergebnis er mit seinem, nur ihm bekannten privaten Schlüssel chiffriert 2. Zur Überprüfung der Signatur liegen dem Empfänger sowohl die Nachricht als auch die Signatur vor, deren verschlüsselten Hash-Wert er zunächst mit dem öffentlichen Schlüssel des Senders dechiffriert 3. Anschließend wird, wie beim Sender, noch einmal der Hash mit der gleichen Hash- Funktion erzeugt, den der Empfänger mit dem entschlüsselten Ergebnis des vorangegangenen Schritts vergleicht 4. Nur wenn beide Werte übereinstimmen 5, wurde die Nachricht offensichtlich nicht manipuliert. Darüber hinaus kann die Nachricht nur vom Sender unterschrieben worden sein, da nur er im Besitz des privaten Signaturschlüssels ist und nur der dazu passende öffentliche Schlüssel den chiffrierten Hash-Wert entschlüsseln kann. Der Message Authentication Code (MAC) erweitert das Funktionsprinzip der Hash-Funktion, indem er zur Berechnung des digitalen Fingerabdrucks noch einen geheimen, nur dem Sender und Empfänger bekannten symmetrischen Schlüssel (Secret Key) verwendet. Berechnet der Empfänger nach dem Erhalt einer Nachricht den gleichen MAC wie der Sender, so kann er von folgenden Annahmen ausgehen: 36

11 Konzepte im SAP-Umfeld 2.1 Sender Empfänger Nachricht Hash A3d641 Nachricht und Signatur A3d641 A3d641 privater Schlüssel des Senders A3d641 öffentlicher Schlüssel des Senders Nachricht Abbildung 2.1 Digitale Signatur Die Nachricht wurde auf dem Weg vom Sender zum Empfänger nicht verändert. Eine Manipulation der Daten durch Dritte hätte zu einer Abweichung zwischen dem neu berechneten MAC und dem MAC des Senders geführt. Weiterhin kann ausgeschlossen werden, dass ein Angreifer einen neuen gültigen MAC für von ihm geänderte Daten in die Kommunikation eingeschleust hat, da er nicht in Besitz des geheimen Schlüssels ist. Die Nachricht wurde vom Sender erstellt, da nur er im Besitz des geheimen Schlüssels ist, mit dem sich ein gültiger MAC berechnen lässt. Somit erfüllen die digitale Signatur und der MAC die gleichen Sicherheitsziele: Schutz der Integrität und Authentizität elektronischer Daten und Nachrichten. Unterschiede existieren nur hinsichtlich der Authentifizierung: Während der Sender für den MAC nur einen Wissensnachweis über einen geheimen Schlüssel erbringen muss, muss er bei der digitalen Signatur zusätzlich noch im Besitz des digitalen Zertifikats sein. Weiterhin setzt der MAC voraus, dass der geheime Schlüssel zuvor über einen sicheren Kanal an die Kommunikationspartner verteilt wurde. Technisch betrachtet wird durch die Verwendung einer digitalen Signatur oder eines MACs allerdings nur nachgewiesen, dass der Sender der Nachricht 37

12 2 Single-Sign-on-Technologien und -Standards in Besitz des geheimen bzw. privaten Schlüssels gewesen sein muss. Ein direkter Bezug zur Identität des Senders existiert nicht, weil der Schlüssel keinerlei Zusatzinformationen beinhaltet, die dem Empfänger weitere Auskünfte über den Inhaber liefern. Offensichtlich reicht der öffentliche Schlüssel nicht alleinig dazu aus, um einen sicheren und vertrauenswürdigen Kanal zwischen den Kommunikationspartnern zu etablieren. An dieser Stelle kommen die digitalen Zertifikate ins Spiel, mit denen die Identität des Besitzers eines öffentlichen Schlüssels beglaubigt wird. Auf diese Weise können die Empfänger einer Nachricht feststellen, ob die Daten tatsächlich vom angegebenen Absender signiert worden sind. Herausgegeben werden die digitalen Zertifikate von sogenannten Zertifizierungsstellen (Certificate Authority, CA). Ein digitales Zertifikat enthält in der Regel die folgenden Angaben: den Namen oder eine andere eindeutige Bezeichnung des Inhabers des öffentlichen Schlüssels den Namen oder eine andere eindeutige Bezeichnung der Zertifizierungsstelle den öffentliche Schlüssel, der mit dem Zertifikat beglaubigt wird den Gültigkeitszeitraum des Zertifikats die von der Zertifizierungsstelle vergebene Seriennummer des Zertifikats den von der Zertifizierungsstelle eingeräumten Verwendungszweck des öffentlichen Schlüssels im Zertifikat (z. B. Datenverschlüsselung, Signaturprüfung) Zu all diesen Informationen berechnet die Zertifizierungsstelle eine digitale Signatur, die sie dem Zertifikat ebenfalls hinzufügt und damit ihrerseits bestätigt, alle aufgeführten Angaben zur Identität des Inhabers sorgfältig geprüft zu haben. Am weitesten verbreitet sind heute Zertifikate nach dem X.509- Standard der International Telecommunication Union (ITU), deren Struktur und Inhalt weitestgehend den oben aufgeführten Angaben entsprechen. In der aktuellen Version 3 (X.509v3) lassen sich noch zusätzliche, vom Standard vorgegebene sowie benutzerspezifische Attribute in Form von sogenannten Zertifikaterweiterungen (Extensions) angeben, um z. B. die Verwaltung von Identitäten in bestimmten Anwendungsbereichen zu vereinfachen. Da grundsätzlich jeder Besitzer eines Schlüsselpaars Zertifikate ausstellen kann, spielt die Zertifizierungsstelle eine entscheidende Rolle. 38

13 Konzepte im SAP-Umfeld 2.1 Als unabhängige Dritte beglaubigen Zertifizierungsstellen die Identität der Besitzer öffentlicher Schlüssel und übernehmen damit eine ähnliche Rolle wie ein Notar, dem beide Kommunikationspartner ihr Vertrauen schenken. Abhängig davon, welcher Aufwand für die Überprüfung der Identitäten erbracht wird, bezeichnen von den Zertifizierungsstellen definierte Qualitätsklassen die Vertrauenswürdigkeitsstufe des öffentlichen Schlüssels und schränken seinen Gebrauch entsprechend ein. Zertifikate für den privaten Gebrauch sind häufig nur an eine gültige -Adresse gebunden und können über ein Online-Formular bestellt werden. Hingegen erfordert der kommerzielle Einsatz stärkere Identitätsnachweise, wie z. B. einen aktuellen Handelsregisterauszug oder sogar das persönliche Erscheinen des Schlüsselbesitzers. Zertifizierungsstellen unterscheiden zudem zwischen Zertifikaten für Endanwender (Benutzerzertifikate) und Serverzertifikaten. Bei der Verwendung von Benutzerzertifikaten ist der Benutzer aktiv und unmittelbar in den Signaturprozess eingebunden. Dass heißt, dass er nach der Prüfung (Inaugenscheinnahme) der Daten den Signaturprozess lokal auf einer ihm zugeordneten Anzeige- und Signaturanwendungskomponente, z. B. auf einem PC mit Kartenlesegerät und Signaturkarte, startet. Im Gegensatz dazu werden die Daten beim Einsatz eines Serverzertifikats mit einem benutzerunabhängigen Schlüsselpaar unterschrieben. Die zu signierenden Daten werden an den Server geschickt, der den Signaturprozess auch ohne vorherige Interaktion mit dem Anwender mit seinem eigenen Schlüsselpaar durchführt. Insbesondere der Einsatz von Benutzerzertifikaten setzt technische Komponenten und Prozesse voraus, die auch als Public Key Infrastructure (PKI) bezeichnet werden und entweder im Unternehmen selbst oder durch einen externen Dienstleister erbracht werden müssen. Um dem Zertifikat und damit dem Sender sein Vertrauen zu schenken, muss der Empfänger zunächst prüfen, ob das Zertifikat die Signatur einer von ihm als vertrauenswürdig eingestuften Zertifizierungsstelle trägt. Solche Zertifikate werden bei international anerkannten Herausgebern in der Regel von den Herstellern der Prüfkomponente (z. B. Browser, Anwendungsserver) beigelegt und müssen somit nicht noch zusätzlich installiert werden. Dennoch kann es vorkommen, dass auch diese Zertifikate in den Prüfkomponenten aktualisiert werden müssen. 39

14 2 Single-Sign-on-Technologien und -Standards Es stellt sich nun noch die Frage, wie die Echtheit der von der Zertifizierungsstelle geleisteten Unterschrift geprüft wird das Zertifikat der Certificate Authority (CA) müsste wiederum selbst von einer ihr übergeordneten Stelle beglaubigt worden sein usw. Für eine praktische Umsetzung dieses rekursiven Modells ohne Abbruchkriterium ist es erforderlich, dass an der Spitze einer solchen Zertifizierungshierarchie oder Zertifikatskette eine vertrauenswürdige Wurzelinstanz (Root-CA) stehen muss, die sich ihr Zertifikat selbst ausgestellt hat. Solche Zertifikate werden auch als selbst signierte Wurzelzertifikate (self-signed Root Certificates) bezeichnet. Die Benutzeranmeldung über X.509-Zertifikate wird in der Regel von allen gängigen Webbrowsern unterstützt. Diese richten beim Zugriff auf eine geschützte Ressource eine Secure-Sockets-Layer-Verbindung (SSL) zum Server mit bidirektionaler, d. h. beidseitiger (mutual) Authentifizierung, ein. Dabei überprüft der Webbrowser nicht nur die Identität des Webservers über das X.509-Zertifikat, sondern der Webserver fordert auch ein gültiges Zertifikat vom Benutzer an, bevor es zu einem erfolgreichen Verbindungsaufbau kommt. Secure Sockets Layer (SSL) und Transport Layer Security (TLS) Bereits 1994 entsprach die Firma Netscape Communications Corporation dem Wunsch nach einem einfachen, für den Benutzer weitestgehend transparenten Mechanismus zum Schutz vertraulicher Daten und zur sicheren Authentifizierung von Kommunikationspartnern im Internet mit der Veröffentlichung der Version 1.0 des SSL-Protokolls (Secure Sockets Layer). Die damalige Marktdominanz des Browsers Netscape Navigator verhalf SSL zu einer schnellen Verbreitung. SSL avancierte zum offiziellen Internetstandard und erhielt im Januar 1999 in der Version 3.0 den Rang eines RFC-Standards der Internet Engineering Task Force (IETF). RFC 2246 benannte SSL 3.0 in TLS (Transport Layer Security) 1.0 um, nahm aber sonst keine wesentlichen Änderungen an den ursprünglichen Protokollmechanismen vor. Seit April 2006 existiert eine aktualisierte Fassung in der Version 1.1 (RFC 4346). SSL/TLS ist im ISO-/OSI-Referenzmodell oberhalb der Transport- und unterhalb der Anwendungsschicht angesiedelt. In der Praxis kommt in der Regel die Sicherung von HTTP-Verbindungen über SSL zum Einsatz, die der Browser mit dem Protokollpräfix einleitet. Da SSL/TLS an kein bestimmtes Anwendungsprotokoll gebunden ist, kann es aber ebenso gut in Verbindung mit FTP oder Telnet eingesetzt werden. Auf diese Weise baut SSL/TLS zwischen zwei Kommunikationspartnern eine sichere Punkt-zu-Punkt-Verbindung auf, über die alle zu übertragenden Informationen gleich behandelt werden. Zertifikate decken allerdings die Anforderungen an ein SSO-System nur bedingt ab. Grundsätzlich können sie natürlich als Anmeldeersatz verwendet 40

15 Konzepte im SAP-Umfeld 2.1 werden, sofern der Empfänger den von der Zertifizierungsstelle attestierten Identitätsdaten im Benutzerzertifikat sein Vertrauen schenkt. Dennoch fügen sich Benutzerzertifikate nur schwer als Pendant einer Anmeldebestätigung in das gängige Bild eines SSO-Systems ein. Zertifikate verfügen in der Regel über eine wesentlich längere Gültigkeit als eine durchschnittliche Benutzeranmeldung, die häufig nur einige Minuten oder maximal Stunden andauert. Diesem Unterschied trägt unter anderem der im Vergleich zur Systemanmeldung wesentlich aufwendigere Prozess der Benutzeridentifizierung bei der Registrierung und Herausgabe eines Zertifikats Rechnung. Außerdem zeigen Zertifikate sich vergleichsweise unflexibel bei der Aufnahme zusätzlicher Benutzerattribute, die z. B. für die Anmeldung an bestimmten Systemen erforderlich wären. Einmal ausgestellt kann das Zertifikat nicht mehr um zusätzliche Informationen ergänzt werden es würde seine Gültigkeit verlieren. Hingegen sind Zertifikate eine sehr sichere Option für die Primärauthentifizierung am IdP, um daraufhin eine leichtgewichtigere SSO-Technologie für die Anmeldung des Users an anderen Systemen zu verwenden SAP Logon Ticket Eine Alternative zu Zertifikaten sind die sogenannten Anmelde-Cookies. Ein Anmelde-Cookie wird dem Benutzer nur nach einer zuvor erfolgreich durchgeführten Anmeldung über herkömmliche Mechanismen, wie z. B. Benutzername und Passwort, oder stärkere Authentifizierungsverfahren, wie z. B. Zertifikate, durch eine zentrale Komponente im Netzwerk ausgestellt, die eine unternehmensweite Sicht über die Identitäten und die ihnen zugeordneten Benutzerkennungen liefert. Einmal im Besitz eines gültigen Anmelde-Cookies, wird es vom Webbrowser 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 Anmelde-Cookie getroffenen Aussage, dass sich sein Besitzer zuvor erfolgreich am Aussteller des Cookies angemeldet hat, wird dem Benutzer der Zugriff gewährt. Grundsätzliche Voraussetzung dafür ist eine Vertrauensbeziehung zwischen dem Aussteller und den Anwendungen, die mittels einer PKI und des Austauschs von Zertifikaten außerhalb des eigentlichen Single-Sign-on-Prozesses etabliert werden kann. Ob über den Besitz des Anmelde-Cookies hinaus noch weitere Informationen vonseiten des Benutzers für eine erneute Authentifizierung notwendig sind, bleibt den jeweiligen Anwendungen überlassen. 41

16 SSL mit X.509-Client-Zertifikaten diese Kombination wird fast von jedem System unterstützt. Sehen Sie, wie Sie auf der Grundlage bewährter Technologien Single Sign-on mit Ihrem SAP-System in Browserszenarien erreichen können. 4 Workshops: Browser-Single-Sign-on mit Zertifikaten Wie bereits in Abschnitt 2.1.1,»Digitale Signatur und Zertifikate«, erläutert, sind Zertifikate ein sehr weit verbreitetes Mittel zur Authentifizierung von Systemen und Benutzern und die Grundlage von SSL. Auch in SAP-Systemen hat der Browser als Schnittstelle zwischen Benutzer und SAP-System schon längst dieselbe Bedeutung wie das SAP GUI. Moderne Browser verfügen über eine Zertifikat- und Schlüsselverwaltung. In dieser können Zertifikate und ihre dazugehörigen privaten Schlüssel sicher im Arbeitsplatzcomputer des Benutzers abgelegt werden. So kann sich ein Benutzer beim Besuchen einer Webanwendung mithilfe seines Zertifikats, das ihm von seiner Zertifizierungsstelle ausgestellt wurde, authentifizieren. Die Authentifizierung mittels Benutzerzertifikat erfolgt auf der Basis der vorhergehenden Authentifizierung am Desktop, die den Zugriff auf die Schlüsselverwaltung des Browsers ermöglicht hat. Für diese Art von Single Sign-on müssen auf den beteiligten Systemen die folgenden Voraussetzungen erfüllt sein: Die von der Zertifizierungsstelle ausgestellten Benutzerzertifikate müssen auf die Arbeitsplätze der Benutzer verteilt werden. Falls an einem Arbeitsplatz mehrere Benutzer arbeiten können, muss sichergestellt werden, dass jeder Benutzer nur auf sein eigenes Zertifikat zugreifen darf. Zertifikate können ungültig werden. Abgelaufene oder zurückgerufene Zertifikate müssen durch neue ersetzt werden können. Die Server müssen so konfiguriert werden, dass sie den Zertifikaten vertrauen, die die Zertifizierungsstelle ausgestellt hat. Außerdem muss es möglich sein, den Benutzer anhand eines vorliegenden Zertifikats eindeutig zu identifizieren. 93

17 4 Workshops: Browser-Single-Sign-on mit Zertifikaten Die folgenden beiden Workshopteile behandeln daher. 1. Die sichere Verteilung von Benutzerzertifikaten im Unternehmen. 2. Die Konfiguration von ABAP-Systemen zur Benutzer-authentifizierung mittels X.509-Zertifikaten über SSL-gesicherte Verbindungen. Der erste Teil befasst sich mit Realisierung des Szenarios mit Hilfe des Microsoft Active Directory und den Active Directory Certificate Services. Der zweite Teil beschreibt die Einbindung des SAP Trust Centers, einer SAP-eigenen Zertifizierungsstelle, speziell für SAP Kunden. 4.1 Workshop: Active Directory Certificate Services Um ein unternehmensweites Single Sign-on zu ermöglichen, wird häufig das Microsoft Active Directory verwendet. Benutzer und Netzwerkressourcen werden hier in sogenannten Domänen verwaltet. Die Endanwender melden sich an ihrem Desktop an und können so auf eine Vielzahl von Diensten im Netzwerk wie Drucker, File Shares oder Webserver zugreifen, ohne sich dabei erneut authentifizieren zu müssen. Mithilfe der Active Directory Certificate Services (AD CS) kann das Active Directory auch als Zertifizierungsstelle betrieben werden. So kann für jeden Benutzer in der Domäne ein Zertifikat ausgestellt werden, das für die Authentifizierung verwendet werden kann. Die Ausstellung sowie die Verteilung der Zertifikate wird ebenfalls vom Active Directory übernommen und kann voll automatisiert werden. Ein kostengünstiger Betrieb der Zertifizierungsstelle ist somit gewährleistet. Über die Active Directory Certificate Services Seit Windows Server 2008 sind die AD CS als eigene Serverrolle installierbar. In Windows Server 2003 ist dieselbe Funktion als die optionale Windows-Komponente mit dem Namen Certificate Services enthalten. ABAP-Systeme unterstützen die Anmeldung an Webanwendungen mit SSL und X.509-Zertifikaten. Jedem SAP-Benutzer im System kann ein Zertifikat zugeordnet werden, mit dem er identifiziert werden kann. Diese Art der Anmeldung wird schon seit dem SAP-Basisrelease 6.40 unterstützt und eignet sich daher auch sehr gut zur Integration von älteren SAP-Systemen. 94

18 Workshop: Active Directory Certificate Services 4.1 In diesem Workshop werden Sie lernen, wie Sie Ihr Active Directory als Zertifizierungsstelle betreiben können, um den Domänenbenutzern Single Signon zu ihren SAP-Systemen zu ermöglichen Einführung in das Szenario Ziel ist es, dass ein Domänenbenutzer nach der erfolgreichen Authentifizierung an seinem Desktop, der Teil der Domäne ist, ohne erneute Anmeldung auf den SAP NetWeaver Application Server ABAP zugreifen können. Der Zugriff erfolgt mit dem Browser, und die Verbindung ist mit SSL gesichert. Das Active Directory dient hierbei als Authentifizierungs- und Zertifizierungsstelle. Damit verwaltet es die Benutzer in der Domäne und deren Benutzerzertifikate. Die Benutzerzertifikate werden voll automatisch auf die Desktops der authentifizierten Benutzer verteilt. Eine Aktion vonseiten des Benutzers bzw. des Administrators der Domäne ist nicht erforderlich. Grundlage dieses Systemverhaltens ist eine Gruppenrichtlinie, die das sogenannte Certificate Autoenrollment in der Domäne freischaltet. Das SAP-System vertraut dem Active Directory als Zertifizierungsstelle. Damit gewährt es allen Domänenbenutzern mit einem gültigen Zertifikat von der Zertifizierungsstelle den Zugriff auf seine Daten. Des Weiteren wird in der Tabelle USREXTID die Zuordnung aller ausgestellten Zertifikate zu deren SAP-Benutzen gepflegt. So kann ein Domänenbenutzer anhand seines Benutzerzertifikats eindeutig als Benutzer im SAP-System identifiziert werden. Active Directory (AD) CSR Authentication Service (AS) Zertifizierungsstelle (AD CS) Principal Datenbank Zertifikat- Datenbank Zertifikat öffentlicher und privater Schlüssel AD CS Vertrauensbeziehung Desktop Browser öffentlicher und privater Schlüssel des Benutzers SAP NetWeaver AS ABAP Zer fikat CN=JOHND, O=ADCA, C=US CN=ALICEO, O=ADCA, C=US CN=BOBJ, O=ADCA, C=US SAP-Benutzer JOHND ALICEO BOBJ Abbildung 4.1 Ausstellung der Benutzerzertifikate und Anmeldung am SAP-System 95

19 4 Workshops: Browser-Single-Sign-on mit Zertifikaten Abbildung 4.1 zeigt das Gesamtbild. 1 Möchte sich ein Benutzer an seinem Desktop anmelden, wird eine Anfrage an den Authentication Service des Active Directorys gestellt. Ist der eingegebene Benutzername mitsamt dem Passwort korrekt, wird dem Benutzer der Zugriff auf seinen Desktop gewährt. 2 Aufgrund der in der Domäne gültigen Gruppenrichtlinie für das Certificate Autoenrollment wird jetzt für den neu angemeldeten Benutzer ein Zertifikatantrag (Certificate Signing Request, CSR) an die Zertifizierungsstelle geschickt. Zu diesem Zweck wird ein asymmetrisches Schlüsselpaar generiert. Der private Schlüssel wird dazu verwendet, den Zertifikatantrag zu signieren, und der öffentliche Schlüssel wird dem Antrag beigelegt. Weiter ist der private Schlüssel in der Windows-Zertifikatsverwaltung abgespeichert; nur der Benutzer, für den der Schlüssel generiert wurde, kann ihn verwenden. Existiert für den jeweiligen Benutzer bereits ein Zertifikat mitsamt dem Schlüsselpaar, wird keine Zertifikatanfrage gestartet. 3 Die Zertifizierungsstelle im Active Directory prüft den Zertifikatantrag. Sie erstellt daraufhin ein Benutzerzertifikat, dem der im Zertifikatantrag mitgeschickte öffentliche Schlüssel beilegt wird. Schließlich wird das Benutzerzertifikat mit dem eigenen privaten Schlüssel signiert und der Antwort beigelegt. Sobald das Zertifikat am Desktop angekommen ist, wird es im Windows-Zertifikatspeicher abgespeichert. 4 Wenn der Domänenbenutzer eine mit SSL gesicherte Seite des AS ABAP öffnen möchte, übermittelt der Server die Liste der vertrauenswürdigen Zertifizierungsstellen. Der Browser findet im Windows-Zertifikatspeicher das im vorherigen Schritt ausgestellte Zertifikat mitsamt dem privaten Schlüssel und verwendet es zur Authentifizierung am Server. Der AS ABAP prüft nun, ob das Zertifikat vertrauenswürdig ist, dann wird der Benutzer anhand der Zuordnung des SAP-Benutzers zum Zertifikat in der Tabelle USREXTID authentifiziert. Er ist nun am SAP-System angemeldet Systemvoraussetzungen Für die Umsetzung des in diesem Workshop behandelten Szenarios werden die in Tabelle 4.1 aufgeführten Systeme mit den entsprechend installierten Softwarekomponenten benötigt. 96

20 Workshop: Active Directory Certificate Services 4.1 System Windows Active Directory/ Zertifizierungsstelle Desktops der Benutzer SAP-System Software Microsoft Windows Server 2008 Enterprise mit Active Directory Windows Server 2003 Enterprise mit Active Directory Services ab Schema Version 34 Microsoft-Desktop-Betriebssysteme wie Windows XP (ab Service Pack 2) Windows Vista Windows 7 SAP NetWeaver AS ABAP 6.40 oder höher Tabelle 4.1 Systemvoraussetzungen Konfigurationsschritte Die Konfigurationsschritte dieses Workshops werden mit einem AS ABAP 7.00 und Windows Server 2008 bzw. Windows 7 dokumentiert. Als Browser wird der Microsoft Internet Explorer verwendet (es kann jeder Browser, der den Windows-Schlüsselspeicher verwendet, genutzt werden). Für jeden Domänenbenutzer, den Sie in diesem Szenario verwenden möchten, muss bereits ein passender SAP-Benutzer im SAP-System vorhanden sein, z. B. tdcwdf09\johnd in der Domäne und»johnd«im SAP-System. Zertifikat-Enrollment mit Genehmigungsprozess Im Workshop wird das Certificate Autoenrollment beschrieben. Dies bedeutet, dass zur Ausstellung bzw. Erneuerung eines Zertifikats keine Interaktion vonseiten des Administrators bzw. des Benutzers erforderlich ist. Diese Schritte können jedoch auch mit Genehmigungsprozessen, z. B. durch einen Administrator, versehen werden. Installation der Zertifizierungsstelle für Ihre Domäne Um das Active Directory als Zertifizierungsstelle zu betreiben, müssen die Active Directory Certificate Services installiert werden. Diese können unmittelbar auf dem Domänencontroller oder auf jedem anderen Server der Domäne installiert werden. 1. Starten Sie den Server Manager auf dem Desktop, der zu Ihrer Zertifizierungsstelle werden soll. Den Server Manager finden Sie im Startmenü unter Settings Control Panel Administrative Tools Server Manager. 97