Single Sign-on mit SAP

Bonn � Boston

Martijn de Boer, Mathias Essenpreis, Stefanie García Laule, Martin Raepple

Single Sign-on mit SAP®

Lösungen für die Praxis

1627.book Seite 3 Donnerstag, 7. Oktober 2010 10:39 10

Auf einen Blick

TEIL I Grundlagen

1 Grundlegende Begriffe und Konzepte ................................. 21

2 Single-Sign-on-Technologien und -Standards ..................... 35

TEIL II Single Sign-on für Benutzerschnittstellen

3 Workshop: Single Sign-on mit Kerberos für SAP GUI .......... 89

4 Workshops: Browser-Single-Sign-on mit Zertifikaten .......... 93

5 Workshop: Single Sign-on mit SPNEGO ............................. 139

6 Workshops: Single Sign-on für Webanwendungen mit SAML 2.0 ..................................................................... 159

7 Workshop: OpenID mit einem externen Portal ................... 215

TEIL III Single Sign-on mit Webservices

8 Workshops: Single Sign-on zum AS ABAP als WS-Provider ................................................................. 237

9 Workshop: Single Sign-on in SAP NetWeaver BPM ............ 321

Anhang

A Fehleranalyse für die SAML- und X.509-Authentifizierung ..................................................... 365

B Literatur und weiterführende Websites .............................. 367

C Die Autoren ....................................................................... 369


7

Inhalt

Vorwort ................................................................................................... 13Einleitung ................................................................................................. 15

TEIL I Grundlagen

1 Grundlegende Begriffe und Konzepte .................................. 21

1.1 SSO und verwandte Konzepte ................................................. 211.2 Chancen und Risiken ............................................................... 221.3 Terminologie ........................................................................... 23

1.3.1 Security Assertion ....................................................... 231.3.2 Identity Provider ......................................................... 231.3.3 Security Token Service ................................................ 241.3.4 Service Provider .......................................................... 24

1.4 Technische und organisatorische Anforderungen ..................... 251.4.1 SSO im Unternehmen ................................................. 261.4.2 SSO zwischen Unternehmen ....................................... 27

1.5 Identitätsverwaltung ................................................................ 30

2 Single-Sign-on-Technologien und -Standards ..................... 35

2.1 Konzepte im SAP-Umfeld ........................................................ 362.1.1 Digitale Signatur und Zertifikate .................................. 362.1.2 SAP Logon Ticket ........................................................ 412.1.3 SAML für Web-Single-Sign-on .................................... 442.1.4 SAML für Webservices ................................................ 602.1.5 Kerberos ..................................................................... 702.1.6 OpenID ....................................................................... 762.1.7 Vergleich der SSO-Technologien ................................. 81

2.2 Single-Sign-on-Szenarien mit SAP NetWeaver ......................... 83

TEIL II Single-Sign-on für Benutzerschnittstellen

3 Workshop: Single Sign-on mit Kerberos für SAP GUI ......... 89

3.1 Einführung in das Szenario ....................................................... 903.2 Systemvoraussetzungen ........................................................... 913.3 Konfiguration und Test des Szenarios ....................................... 91


Inhalt

8

3.4 Wichtige SAP-Hinweise ........................................................... 923.5 Zusammenfassung ................................................................... 92

4 Workshops: Browser-Single-Sign-on mit Zertifikaten ........ 93

4.1 Workshop: Active Directory Certificate Services ....................... 944.1.1 Einführung in das Szenario .......................................... 954.1.2 Systemvoraussetzungen ............................................... 964.1.3 Konfigurationsschritte ................................................. 974.1.4 Szenario testen ........................................................... 1144.1.5 Fehleranalyse und -behebung ..................................... 1154.1.6 Wichtige SAP-Hinweise ............................................... 1174.1.7 Zusammenfassung ....................................................... 117

4.2 Workshop: SAP Trust Center Service ........................................ 1184.2.1 Einführung in das Szenario .......................................... 1184.2.2 Systemvoraussetzungen ............................................... 1204.2.3 Konfigurationsschritte ................................................. 1204.2.4 Zusammenfassung ....................................................... 137

5 Workshop: Single Sign-on mit SPNEGO ............................. 139

5.1 Einführung in das Szenario ....................................................... 1395.2 Systemvoraussetzungen ........................................................... 1425.3 Konfigurationsschritte .............................................................. 142

5.3.1 Servicebenutzer in der Domäne erstellen .................... 1435.3.2 SPN zuordnen ............................................................. 1445.3.3 Benutzerspezifisches UME-Attribut für den

Kerberos Prinicpal Name hinzufügen ........................... 1445.3.4 Kerberos-Konfiguration für neuen Realm

im Portal anlegen ........................................................ 1455.3.5 Authentication Stack im Portal für SPNEGO

konfigurieren .............................................................. 1485.3.6 Domänen- und Portalbenutzer anlegen ....................... 149

5.4 Szenario testen ........................................................................ 1505.5 Fehleranalyse und -behebung .................................................. 1525.6 Wichtige SAP-Hinweise ........................................................... 1565.7 Zusammenfassung ................................................................... 157

6 Workshops: Single Sign-on für Webanwendungen mit SAML 2.0 ........................................................................ 159

6.1 Workshop: Web-SSO zwischen Unternehmen .......................... 1596.1.1 Einführung in das Szenario .......................................... 160


Inhalt

9

6.1.2 Systemvoraussetzungen .............................................. 1626.1.3 Konfigurationsschritte ................................................. 1636.1.4 Szenario testen ........................................................... 1836.1.5 Fehleranalyse und -behebung ..................................... 1846.1.6 Wichtige SAP-Hinweise ............................................... 1866.1.7 Zusammenfassung ....................................................... 186

6.2 Workshop: Web-SSO in einer heterogenen Systemlandschaft ..................................................................... 1876.2.1 Einführung in das Szenario .......................................... 1876.2.2 Systemvoraussetzungen .............................................. 1906.2.3 Konfigurationsschritte ................................................. 1906.2.4 Szenario testen ........................................................... 2056.2.5 Fehleranalyse und -behebung ..................................... 2116.2.6 Wichtige SAP-Hinweise ............................................... 2136.2.7 Zusammenfassung ....................................................... 213

7 Workshop: OpenID mit einem externen Portal ................... 215


7.3.1 OpenID-URL registrieren ............................................ 2207.3.2 OpenID-Komponenten im Portal installieren .............. 2207.3.3 Neue OpenID-Anmeldeanwendung aktivieren ............ 2237.3.4 UME-Attribut für OpenID-URL anlegen ...................... 2257.3.5 Authentication Stack für OpenID konfigurieren ........... 225

7.4 Szenario testen ........................................................................ 2277.5 Fehleranalyse und -behebung .................................................. 2307.6 Wichtige SAP-Hinweise ........................................................... 2327.7 Zusammenfassung ................................................................... 233

TEIL III Single-Sign-on mit Webservices

8 Workshops: Single Sign-on zum AS ABAP als WS-Provider 237

8.1 Einführung ............................................................................... 2388.2 Single Sign-on zwischen einer Serveranwendung und

AS ABAP mit SAML-Sender-Vouches ....................................... 2418.2.1 Konfiguration des WS-Providers für SAML-Sender-

Vouches ...................................................................... 2428.2.2 Konfiguration des WS-Providers .................................. 244


Inhalt

10

8.2.3 Selbst signierten Signaturschlüssel für den WS-Consumer erzeugen .............................................. 246

8.2.4 Vertrauensbeziehung einrichten .................................. 2488.3 Workshop: Single Sign-on mit Apache Axis2 und Apache

Rampart .................................................................................. 2558.3.1 Single Sign-on mit SAML 1.1-Sender-Vouches ............ 2568.3.2 Konfiguration des WS-Providers .................................. 2568.3.3 WS-Consumer erstellen ............................................... 2578.3.4 WS-Consumer konfigurieren ....................................... 2628.3.5 Webservice aufrufen ................................................... 2668.3.6 Vertrauensbeziehung einrichten .................................. 2678.3.7 Szenario testen ........................................................... 2688.3.8 Fehleranalyse und -behebung ..................................... 269

8.4 Workshop: Single Sign-on mit Sun Metro 2.0 .......................... 2708.4.1 Single Sign-on mit SAML 1.1-Sender-Vouches ............ 2718.4.2 WS-Provider konfigurieren .......................................... 2718.4.3 WS-Consumer erstellen ............................................... 2728.4.4 WS-Consumer konfigurieren ....................................... 2758.4.5 Webservice aufrufen ................................................... 2778.4.6 Vertrauensbeziehung einrichten .................................. 2788.4.7 Szenario testen ........................................................... 2798.4.8 Fehleranalyse und -behebung ..................................... 279

8.5 Workshop: Single Sign-on mit anderen EE5-Plattformen .......... 2808.5.1 Single Sign-on mit SAML 1.1-Sender-Vouches ............ 2818.5.2 WS-Provider konfigurieren .......................................... 2828.5.3 WS-Consumer erstellen ............................................... 2828.5.4 WS-Consumer konfigurieren ....................................... 2828.5.5 Vertrauensbeziehung einrichten .................................. 2838.5.6 Szenario testen ........................................................... 2838.5.7 Fehleranalyse und -behebung ..................................... 283

8.6 Workshop: Single Sign-on mit einer .Net-Serveranwendung .... 2838.6.1 Single Sign-on mit SAML 1.1-Sender-Vouches ............ 2848.6.2 WS-Provider konfigurieren .......................................... 2858.6.3 WS-Consumer erstellen ............................................... 2858.6.4 WS-Consumer konfigurieren ....................................... 2858.6.5 Vertrauensbeziehung einrichten .................................. 2868.6.6 Szenario testen ........................................................... 2878.6.7 Fehleranalyse und -behebung ..................................... 287

8.7 Single Sign-on zwischen Desktop-Anwendungen und dem AS ABAP .................................................................................. 2878.7.1 Authentifizierung mit SAML-Holder-of-Key ................. 288


Inhalt

11

8.7.2 Einführung in das Szenario .......................................... 2898.7.3 Authentifizierung mit X.509-Zertifikaten ..................... 290

8.8 Workshop: Single Sign-on mit X.509-Zertifikaten zwischen einer Java-Desktop-Anwendung mit Sun Metro und AS ABAP 7.00 ......................................................................... 2908.8.1 Provider-Konfiguration anlegen .................................. 2918.8.2 Vertrauensbeziehung einrichten .................................. 2928.8.3 Benutzerabbildung über den Report RSUSREXT .......... 2928.8.4 WS-Consumer erstellen ............................................... 2938.8.5 WS-Consumer konfigurieren ....................................... 2938.8.6 Szenario testen ........................................................... 2938.8.7 Fehleranalyse und -behebung ..................................... 294

8.9 Workshop: Single Sign-on zwischen Microsoft Office und dem AS ABAP .......................................................................... 2948.9.1 Single Sign-on mit SAML 1.1-Holder-of-Key ............... 2958.9.2 Systemvoraussetzungen .............................................. 2978.9.3 ADFS-Security-Token-Service konfigurieren ................ 2988.9.4 Relying Partys mit AS ABAP 7.02 und 7.30

konfigurieren .............................................................. 2998.9.5 Relying Partys mit AS ABAP 7.01 und 7.11

konfigurieren .............................................................. 3028.9.6 Auszustellende Claims konfigurieren ........................... 3048.9.7 Vertrauensbeziehung im SAP-WS-Provider-System

einrichten ................................................................... 3058.9.8 WS-Provider konfigurieren .......................................... 3118.9.9 WS-Consumer erstellen ............................................... 3138.9.10 WS-Consumer konfigurieren ....................................... 3138.9.11 Szenario testen ........................................................... 3168.9.12 Fehleranalyse und -behebung ..................................... 317

8.10 Zusammenfassung ................................................................... 320

9 Workshop: Single Sign-on in SAP NetWeaver BPM ........... 321


9.3.1 Voraussetzungen für die Konfiguration des Szenarios .............................................................. 327

9.3.2 Benutzer für das Szenario anlegen ............................... 3289.3.3 SAP NetWeaver Developer Studio vorbereiten ............ 3309.3.4 BPM-Prozess für Single Sign-on konfigurieren ............. 3349.3.5 Nachrichtenbasierte Authentifizierung einrichten ........ 335


Inhalt

12

9.3.6 Vertrauensbeziehung zwischen WS-Provider und WS-Consumer einrichten ............................................ 338

9.3.7 WS-Provider für Single Sign-on konfigurieren .............. 3469.3.8 WS-Consumer für Single Sign-on konfigurieren ........... 3499.3.9 Abbildungsinformationen des Benutzernamens auf

dem SAP ERP-System pflegen ..................................... 3529.4 Szenario testen ........................................................................ 3549.5 Fehleranalyse und -behebung .................................................. 359

9.5.1 Fehlersuche im AS Java ............................................... 3599.5.2 Fehlersuche im AS ABAP ............................................. 359

9.6 Wichtige SAP-Hinweise ........................................................... 3629.7 Zusammenfassung ................................................................... 362

Anhang ....................................................................................... 363

A Fehleranalyse für die SAML- und X.509-Authentifizierung .................. 365B Literatur und weiterführende Websites .............................................. 367C Die Autoren ....................................................................................... 369

Index ......................................................................................................... 371


35

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 neun-ziger Jahre und dem damit einhergehenden Anstieg zugangsgeschützterWebsites wurde der Ruf nach Lösungen laut, die der Flut von Benutzernamenund Passwörtern Einhalt gebieten können. Schnell wurde mit ersten Lösungs-vorschlägen wie mit dem 1999 eingeführten .NET Passport reagiert, mit demsein Betreiber Microsoft leidgeprüften Internetanwendern einen zentralenAnmeldedienst zur Verfügung stellte. Einmal auf der Passport-Seite regis-triert, erfolgte die Anmeldung bei Microsofts eigenen Online-Diensten wieHotmail oder dem Messenger automatisch und ohne erneute Passwortein-gabe. Dieses Single-Sign-on-System konnte jedoch nie eine nennenswerteVerbreitung unter Anwendern und Anbietern von geschützten Internetdiens-ten verzeichnen. Konkurrenz bekam .Net Passport etwas später durch dieLiberty Alliance: Der im Jahr 2001 von Sun Microsystems gegründete Ver-bund machte sich die Entwicklung offener Standards für ein dezentral orga-nisiertes Single-Sign-on-System zur Aufgabe und bot damit aus organisatori-scher und technologischer Sicht einen Gegenvorschlag zu .NET Passport.Obwohl die von der Liberty Alliance verabschiedeten Konzepte nicht füreinen weltweiten Anmeldedienst im Internet eingesetzt wurden, beeinfluss-ten viele der dort entstandenen Ideen die Entwicklung eines wichtigen Stan-dards für SSO in Unternehmen und zwischen Geschäftspartnern: die SecurityAssertion Markup Language (SAML). SAML gesellt sich zu einer Reihe weitererTechnologien wie digitale Zertifikate, Kerberos und OpenID, die ebenfalls imSAP-Umfeld für SSO von Bedeutung sind und im folgenden Abschnittgenauer betrachtet werden.


36

Single-Sign-on-Technologien und -Standards2

2.1 Konzepte im SAP-Umfeld

Den von SAP unterstützten Technologien und Standards für Single Sign-onliegen unterschiedliche Ansätze zugrunde.

2.1.1 Digitale Signatur und Zertifikate

Betrachten wir zunächst die digitale Signatur, die in vielen nationalen undinternationalen Gesetzesregelungen grundsätzlich mit der klassischen papier-gebundenen Unterschrift juristisch gleichgestellt wird.

Zur Erstellung einer digitalen Signatur kann die asymmetrische Verschlüsse-lung eingesetzt werden. Dabei kommen zwei komplementäre, aber miteinan-der in Beziehung stehende Schlüssel zum Einsatz. Das Schlüsselpaar, beste-hend aus einem privaten und einem öffentlichen Schlüssel (Private undPublic Key), ist so entworfen, dass mit dem öffentlichen Schlüssel verschlüs-selte Daten nur mit dem passenden privaten Schlüssel entschlüsselt werdenkönnen (und umgekehrt: nur mit dem richtigen privaten Schlüssel chiffrierteInformationen 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 Signaturauf die betreffende Nachricht zunächst eine Hash-Funktion anwendet 1,deren Ergebnis er mit seinem, nur ihm bekannten privaten Schlüssel chiff-riert 2. Zur Überprüfung der Signatur liegen dem Empfänger sowohl dieNachricht als auch die Signatur vor, deren verschlüsselten Hash-Wert erzunä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 desvorangegangenen Schritts vergleicht 4. Nur wenn beide Werte übereinstim-men 5, wurde die Nachricht offensichtlich nicht manipuliert. Darüber hin-aus kann die Nachricht nur vom Sender unterschrieben worden sein, da nurer 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 derHash-Funktion, indem er zur Berechnung des digitalen Fingerabdrucks nocheinen geheimen, nur dem Sender und Empfänger bekannten symmetrischenSchlüssel (Secret Key) verwendet. Berechnet der Empfänger nach dem Erhalteiner Nachricht den gleichen MAC wie der Sender, so kann er von folgendenAnnahmen ausgehen:


37

Konzepte im SAP-Umfeld 2.1

Abbildung 2.1 Digitale Signatur

Die Nachricht wurde auf dem Weg vom Sender zum Empfänger nicht verän-dert. Eine Manipulation der Daten durch Dritte hätte zu einer Abweichungzwischen dem neu berechneten MAC und dem MAC des Senders geführt.

Weiterhin kann ausgeschlossen werden, dass ein Angreifer einen neuen gül-tigen MAC für von ihm geänderte Daten in die Kommunikation eingeschleusthat, da er nicht in Besitz des geheimen Schlüssels ist. Die Nachricht wurdevom Sender erstellt, da nur er im Besitz des geheimen Schlüssels ist, mit demsich ein gültiger MAC berechnen lässt.

Somit erfüllen die digitale Signatur und der MAC die gleichen Sicherheits-ziele: Schutz der Integrität und Authentizität elektronischer Daten und Nach-richten. Unterschiede existieren nur hinsichtlich der Authentifizierung: Wäh-rend der Sender für den MAC nur einen Wissensnachweis über einengeheimen Schlüssel erbringen muss, muss er bei der digitalen Signaturzusätzlich noch im Besitz des digitalen Zertifikats sein. Weiterhin setzt derMAC voraus, dass der geheime Schlüssel zuvor über einen sicheren Kanal andie Kommunikationspartner verteilt wurde.

Technisch betrachtet wird durch die Verwendung einer digitalen Signaturoder eines MACs allerdings nur nachgewiesen, dass der Sender der Nachricht

Nachricht

Nachricht und Signatur

privaterSchlüssel des

Senders

A3d641Hash A3d641

öffentlicherSchlüssel des

Senders

A3d641

Nachricht

Sender Empfänger

A3d64144444444441111111111111111111111111111


38


in Besitz des geheimen bzw. privaten Schlüssels gewesen sein muss. Eindirekter Bezug zur Identität des Senders existiert nicht, weil der Schlüssel kei-nerlei Zusatzinformationen beinhaltet, die dem Empfänger weitere Aus-künfte über den Inhaber liefern. Offensichtlich reicht der öffentliche Schlüs-sel nicht alleinig dazu aus, um einen sicheren und vertrauenswürdigen Kanalzwischen den Kommunikationspartnern zu etablieren.

An dieser Stelle kommen die digitalen Zertifikate ins Spiel, mit denen dieIdentität des Besitzers eines öffentlichen Schlüssels beglaubigt wird. Aufdiese Weise können die Empfänger einer Nachricht feststellen, ob die Datentatsächlich vom angegebenen Absender signiert worden sind. Herausgegebenwerden die digitalen Zertifikate von sogenannten Zertifizierungsstellen (Certi-ficate Authority, CA).

Ein digitales Zertifikat enthält in der Regel die folgenden Angaben:

� den Namen oder eine andere eindeutige Bezeichnung des Inhabers des öf-fentlichen Schlüssels

� den Namen oder eine andere eindeutige Bezeichnung der Zertifizierungs-stelle

� 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, Signatur-prüfung)

Zu all diesen Informationen berechnet die Zertifizierungsstelle eine digitaleSignatur, die sie dem Zertifikat ebenfalls hinzufügt und damit ihrerseits bestä-tigt, alle aufgeführten Angaben zur Identität des Inhabers sorgfältig geprüftzu haben. Am weitesten verbreitet sind heute Zertifikate nach dem X.509-Standard der International Telecommunication Union (ITU), deren Strukturund Inhalt weitestgehend den oben aufgeführten Angaben entsprechen. Inder aktuellen Version 3 (X.509v3) lassen sich noch zusätzliche, vom Standardvorgegebene sowie benutzerspezifische Attribute in Form von sogenanntenZertifikaterweiterungen (Extensions) angeben, um z. B. die Verwaltung vonIdentitäten in bestimmten Anwendungsbereichen zu vereinfachen. Dagrundsätzlich jeder Besitzer eines Schlüsselpaars Zertifikate ausstellen kann,spielt die Zertifizierungsstelle eine entscheidende Rolle.


39


Als unabhängige Dritte beglaubigen Zertifizierungsstellen die Identität derBesitzer öffentlicher Schlüssel und übernehmen damit eine ähnliche Rollewie ein Notar, dem beide Kommunikationspartner ihr Vertrauen schenken.Abhängig davon, welcher Aufwand für die Überprüfung der Identitätenerbracht wird, bezeichnen von den Zertifizierungsstellen definierte Qualitäts-klassen die Vertrauenswürdigkeitsstufe des öffentlichen Schlüssels undschränken seinen Gebrauch entsprechend ein. Zertifikate für den privatenGebrauch sind häufig nur an eine gültige E-Mail-Adresse gebunden und kön-nen über ein Online-Formular bestellt werden. Hingegen erfordert der kom-merzielle Einsatz stärkere Identitätsnachweise, wie z. B. einen aktuellenHandelsregisterauszug oder sogar das persönliche Erscheinen des Schlüssel-besitzers.

Zertifizierungsstellen unterscheiden zudem zwischen Zertifikaten für Endan-wender (Benutzerzertifikate) und Serverzertifikaten.

� Bei der Verwendung von Benutzerzertifikaten ist der Benutzer aktiv undunmittelbar in den Signaturprozess eingebunden. Dass heißt, dass er nachder Prüfung (Inaugenscheinnahme) der Daten den Signaturprozess lokalauf einer ihm zugeordneten Anzeige- und Signaturanwendungskompo-nente, z. B. auf einem PC mit Kartenlesegerät und Signaturkarte, startet.

� Im Gegensatz dazu werden die Daten beim Einsatz eines Serverzertifikatsmit einem benutzerunabhängigen Schlüsselpaar unterschrieben. Die zu sig-nierenden Daten werden an den Server geschickt, der den Signaturprozess– auch ohne vorherige Interaktion mit dem Anwender – mit seinem eige-nen Schlüsselpaar durchführt.

Insbesondere der Einsatz von Benutzerzertifikaten setzt technische Kompo-nenten und Prozesse voraus, die auch als Public Key Infrastructure (PKI)bezeichnet werden und entweder im Unternehmen selbst oder durch einenexternen Dienstleister erbracht werden müssen.

Um dem Zertifikat und damit dem Sender sein Vertrauen zu schenken, mussder Empfänger zunächst prüfen, ob das Zertifikat die Signatur einer von ihmals vertrauenswürdig eingestuften Zertifizierungsstelle trägt. Solche Zertifi-kate werden bei international anerkannten Herausgebern in der Regel vonden Herstellern der Prüfkomponente (z. B. Browser, Anwendungsserver) bei-gelegt und müssen somit nicht noch zusätzlich installiert werden. Dennochkann es vorkommen, dass auch diese Zertifikate in den Prüfkomponentenaktualisiert werden müssen.


40


Es stellt sich nun noch die Frage, wie die Echtheit der von der Zertifizierungs-stelle geleisteten Unterschrift geprüft wird – das Zertifikat der CertificateAuthority (CA) müsste wiederum selbst von einer ihr übergeordneten Stellebeglaubigt worden sein usw. Für eine praktische Umsetzung dieses rekursi-ven Modells ohne Abbruchkriterium ist es erforderlich, dass an der Spitzeeiner solchen Zertifizierungshierarchie oder Zertifikatskette eine vertrauens-würdige Wurzelinstanz (Root-CA) stehen muss, die sich ihr Zertifikat selbstausgestellt hat. Solche Zertifikate werden auch als selbst signierte Wurzelzerti-fikate (self-signed Root Certificates) bezeichnet.

Die Benutzeranmeldung über X.509-Zertifikate wird in der Regel von allengängigen Webbrowsern unterstützt. Diese richten beim Zugriff auf einegeschützte Ressource eine Secure-Sockets-Layer-Verbindung (SSL) zum Ser-ver mit bidirektionaler, d. h. beidseitiger (mutual) Authentifizierung, ein.Dabei überprüft der Webbrowser nicht nur die Identität des Webservers überdas X.509-Zertifikat, sondern der Webserver fordert auch ein gültiges Zertifi-kat vom Benutzer an, bevor es zu einem erfolgreichen Verbindungsaufbaukommt.

Zertifikate decken allerdings die Anforderungen an ein SSO-System nurbedingt ab. Grundsätzlich können sie natürlich als Anmeldeersatz verwendet

Secure Sockets Layer (SSL) und Transport Layer Security (TLS)

Bereits 1994 entsprach die Firma Netscape Communications Corporation demWunsch nach einem einfachen, für den Benutzer weitestgehend transparentenMechanismus zum Schutz vertraulicher Daten und zur sicheren Authentifizierungvon Kommunikationspartnern im Internet mit der Veröffentlichung der Version 1.0des SSL-Protokolls (Secure Sockets Layer). Die damalige Marktdominanz des Brow-sers Netscape Navigator verhalf SSL zu einer schnellen Verbreitung. SSL avanciertezum offiziellen Internetstandard und erhielt im Januar 1999 in der Version 3.0 denRang eines RFC-Standards der Internet Engineering Task Force (IETF). RFC 2246benannte SSL 3.0 in TLS (Transport Layer Security) 1.0 um, nahm aber sonst keinewesentlichen Änderungen an den ursprünglichen Protokollmechanismen vor. SeitApril 2006 existiert eine aktualisierte Fassung in der Version 1.1 (RFC 4346).

SSL/TLS ist im ISO-/OSI-Referenzmodell oberhalb der Transport- und unterhalb derAnwendungsschicht angesiedelt. In der Praxis kommt in der Regel die Sicherung vonHTTP-Verbindungen über SSL zum Einsatz, die der Browser mit dem Protokollpräfixhttps://... einleitet. Da SSL/TLS an kein bestimmtes Anwendungsprotokoll gebun-den ist, kann es aber ebenso gut in Verbindung mit FTP oder Telnet eingesetzt wer-den. Auf diese Weise baut SSL/TLS zwischen zwei Kommunikationspartnern einesichere Punkt-zu-Punkt-Verbindung auf, über die alle zu übertragenden Informati-onen gleich behandelt werden.


41


werden, sofern der Empfänger den von der Zertifizierungsstelle attestiertenIdentitätsdaten im Benutzerzertifikat sein Vertrauen schenkt. Dennoch fügensich Benutzerzertifikate nur schwer als Pendant einer Anmeldebestätigung indas gängige Bild eines SSO-Systems ein. Zertifikate verfügen in der Regel übereine wesentlich längere Gültigkeit als eine durchschnittliche Benutzeranmel-dung, die häufig nur einige Minuten oder maximal Stunden andauert. Die-sem Unterschied trägt unter anderem der im Vergleich zur Systemanmeldungwesentlich aufwendigere Prozess der Benutzeridentifizierung bei der Regis-trierung und Herausgabe eines Zertifikats Rechnung. Außerdem zeigen Zer-tifikate sich vergleichsweise unflexibel bei der Aufnahme zusätzlicherBenutzerattribute, die z. B. für die Anmeldung an bestimmten Systemenerforderlich wären. Einmal ausgestellt kann das Zertifikat nicht mehr umzusätzliche Informationen ergänzt werden – es würde seine Gültigkeit verlie-ren. Hingegen sind Zertifikate eine sehr sichere Option für die Primärauthen-tifizierung am IdP, um daraufhin eine leichtgewichtigere SSO-Technologiefür die Anmeldung des Users an anderen Systemen zu verwenden.

2.1.2 SAP Logon Ticket

Eine Alternative zu Zertifikaten sind die sogenannten Anmelde-Cookies. EinAnmelde-Cookie wird dem Benutzer nur nach einer zuvor erfolgreich durch-geführten Anmeldung über herkömmliche Mechanismen, wie z. B. Benutzer-name und Passwort, oder stärkere Authentifizierungsverfahren, wie z. B. Zer-tifikate, durch eine zentrale Komponente im Netzwerk ausgestellt, die eineunternehmensweite Sicht über die Identitäten und die ihnen zugeordnetenBenutzerkennungen liefert.

Einmal im Besitz eines gültigen Anmelde-Cookies, wird es vom Webbrowserdes Benutzers automatisch an die Zielanwendungen übermittelt. Diesenbleibt es nun überlassen, eine Authentifizierungsentscheidung auf derGrundlage der empfangenen Informationen zu fällen. Vertraut die jeweiligeAnwendung der durch das Anmelde-Cookie getroffenen Aussage, dass sichsein Besitzer zuvor erfolgreich am Aussteller des Cookies angemeldet hat,wird dem Benutzer der Zugriff gewährt. Grundsätzliche Voraussetzung dafürist eine Vertrauensbeziehung zwischen dem Aussteller und den Anwendun-gen, die mittels einer PKI und des Austauschs von Zertifikaten außerhalb deseigentlichen Single-Sign-on-Prozesses etabliert werden kann. Ob über denBesitz des Anmelde-Cookies hinaus noch weitere Informationen vonseitendes Benutzers für eine erneute Authentifizierung notwendig sind, bleibt denjeweiligen Anwendungen überlassen.


93

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 Brow-serszenarien 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 vonSystemen und Benutzern und die Grundlage von SSL.

Auch in SAP-Systemen hat der Browser als Schnittstelle zwischen Benutzerund SAP-System schon längst dieselbe Bedeutung wie das SAP GUI. ModerneBrowser verfügen über eine Zertifikat- und Schlüsselverwaltung. In dieserkönnen Zertifikate und ihre dazugehörigen privaten Schlüssel sicher imArbeitsplatzcomputer des Benutzers abgelegt werden. So kann sich einBenutzer beim Besuchen einer Webanwendung mithilfe seines Zertifikats,das ihm von seiner Zertifizierungsstelle ausgestellt wurde, authentifizieren.Die Authentifizierung mittels Benutzerzertifikat erfolgt auf der Basis der vor-hergehenden Authentifizierung am Desktop, die den Zugriff auf die Schlüs-selverwaltung des Browsers ermöglicht hat.

Für diese Art von Single Sign-on müssen auf den beteiligten Systemen die fol-genden Voraussetzungen erfüllt sein:

� Die von der Zertifizierungsstelle ausgestellten Benutzerzertifikate müssenauf die Arbeitsplätze der Benutzer verteilt werden. Falls an einem Arbeits-platz mehrere Benutzer arbeiten können, muss sichergestellt werden, dassjeder Benutzer nur auf sein eigenes Zertifikat zugreifen darf.

� Zertifikate können ungültig werden. Abgelaufene oder zurückgerufeneZertifikate müssen durch neue ersetzt werden können.

� Die Server müssen so konfiguriert werden, dass sie den Zertifikaten ver-trauen, die die Zertifizierungsstelle ausgestellt hat. Außerdem muss esmöglich sein, den Benutzer anhand eines vorliegenden Zertifikats eindeu-tig zu identifizieren.


94

Workshops: Browser-Single-Sign-on mit Zertifikaten4

Die folgenden beiden Workshopteile behandeln daher.

1. Die sichere Verteilung von Benutzerzertifikaten im Unternehmen.

2. Die Konfiguration von ABAP-Systemen zur Benutzer-authentifizierungmittels X.509-Zertifikaten über SSL-gesicherte Verbindungen.

Der erste Teil befasst sich mit Realisierung des Szenarios mit Hilfe des Micro-soft Active Directory und den Active Directory Certificate Services. Der zweiteTeil beschreibt die Einbindung des SAP Trust Centers, einer SAP-eigenen Zer-tifizierungsstelle, speziell für SAP Kunden.

4.1 Workshop: Active Directory Certificate Services

Um ein unternehmensweites Single Sign-on zu ermöglichen, wird häufig dasMicrosoft Active Directory verwendet. Benutzer und Netzwerkressourcenwerden hier in sogenannten Domänen verwaltet. Die Endanwender meldensich an ihrem Desktop an und können so auf eine Vielzahl von Diensten imNetzwerk wie Drucker, File Shares oder Webserver zugreifen, ohne sichdabei erneut authentifizieren zu müssen.

Mithilfe der Active Directory Certificate Services (AD CS) kann das ActiveDirectory auch als Zertifizierungsstelle betrieben werden. So kann für jedenBenutzer in der Domäne ein Zertifikat ausgestellt werden, das für die Authen-tifizierung verwendet werden kann. Die Ausstellung sowie die Verteilung derZertifikate wird ebenfalls vom Active Directory übernommen und kann vollautomatisiert werden. Ein kostengünstiger Betrieb der Zertifizierungsstelleist somit gewährleistet.

ABAP-Systeme unterstützen die Anmeldung an Webanwendungen mit SSLund X.509-Zertifikaten. Jedem SAP-Benutzer im System kann ein Zertifikatzugeordnet werden, mit dem er identifiziert werden kann. Diese Art derAnmeldung wird schon seit dem SAP-Basisrelease 6.40 unterstützt und eignetsich daher auch sehr gut zur Integration von älteren SAP-Systemen.

Über die Active Directory Certificate Services

Seit Windows Server 2008 sind die AD CS als eigene Serverrolle installierbar. InWindows Server 2003 ist dieselbe Funktion als die optionale Windows-Kompo-nente mit dem Namen Certificate Services enthalten.


95

Workshop: Active Directory Certificate Services 4.1

In diesem Workshop werden Sie lernen, wie Sie Ihr Active Directory als Zer-tifizierungsstelle betreiben können, um den Domänenbenutzern Single Sign-on zu ihren SAP-Systemen zu ermöglichen.

4.1.1 Einführung in das Szenario

Ziel ist es, dass ein Domänenbenutzer nach der erfolgreichen Authentifizie-rung an seinem Desktop, der Teil der Domäne ist, ohne erneute Anmeldungauf den SAP NetWeaver Application Server ABAP zugreifen können. DerZugriff erfolgt mit dem Browser, und die Verbindung ist mit SSL gesichert.

Das Active Directory dient hierbei als Authentifizierungs- und Zertifizie-rungsstelle. Damit verwaltet es die Benutzer in der Domäne und derenBenutzerzertifikate. Die Benutzerzertifikate werden voll automatisch auf dieDesktops der authentifizierten Benutzer verteilt. Eine Aktion vonseiten desBenutzers bzw. des Administrators der Domäne ist nicht erforderlich. Grund-lage dieses Systemverhaltens ist eine Gruppenrichtlinie, die das sogenannteCertificate Autoenrollment in der Domäne freischaltet.

Das SAP-System vertraut dem Active Directory als Zertifizierungsstelle. Damitgewährt es allen Domänenbenutzern mit einem gültigen Zertifikat von der Zer-tifizierungsstelle den Zugriff auf seine Daten. Des Weiteren wird in der TabelleUSREXTID die Zuordnung aller ausgestellten Zertifikate zu deren SAP-Benut-zen gepflegt. So kann ein Domänenbenutzer anhand seines Benutzerzertifikatseindeutig als Benutzer im SAP-System identifiziert werden.

Abbildung 4.1 Ausstellung der Benutzerzertifikate und Anmeldung am SAP-System

Active Directory (AD)

Zertifizierungs-stelle (AD CS)

AuthenticationService (AS)

PrincipalDatenbank

Zertifikat-Datenbank

SAP NetWeaverAS ABAP

r

öffentlicher und privater Schlüsseldes Benutzers

öffentlicher und privater SchlüsselAD CS

CSR

Vertrauens-beziehung

Desktop

Browser

Zertifikat

Zer�fikat SAP-Benutzer

CN=JOHND, O=ADCA, C=US JOHND

CN=ALICEO, O=ADCA, C=US ALICEO

CN=BOBJ, O=ADCA, C=US BOBJ


96


Abbildung 4.1 zeigt das Gesamtbild.

1 Möchte sich ein Benutzer an seinem Desktop anmelden, wird eineAnfrage an den Authentication Service des Active Directorys gestellt. Istder eingegebene Benutzername mitsamt dem Passwort korrekt, wird demBenutzer der Zugriff auf seinen Desktop gewährt.

2 Aufgrund der in der Domäne gültigen Gruppenrichtlinie für das Certifi-cate Autoenrollment wird jetzt für den neu angemeldeten Benutzer einZertifikatantrag (Certificate Signing Request, CSR) an die Zertifizierungs-stelle geschickt. Zu diesem Zweck wird ein asymmetrisches Schlüsselpaargeneriert. Der private Schlüssel wird dazu verwendet, den Zertifikatan-trag zu signieren, und der öffentliche Schlüssel wird dem Antrag beige-legt.

Weiter ist der private Schlüssel in der Windows-Zertifikatsverwaltung ab-gespeichert; nur der Benutzer, für den der Schlüssel generiert wurde,kann ihn verwenden.

Existiert für den jeweiligen Benutzer bereits ein Zertifikat mitsamt demSchlüsselpaar, wird keine Zertifikatanfrage gestartet.

3 Die Zertifizierungsstelle im Active Directory prüft den Zertifikatantrag.Sie erstellt daraufhin ein Benutzerzertifikat, dem der im Zertifikatantragmitgeschickte öffentliche Schlüssel beilegt wird. Schließlich wird das Be-nutzerzertifikat mit dem eigenen privaten Schlüssel signiert und der Ant-wort beigelegt. Sobald das Zertifikat am Desktop angekommen ist, wirdes 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ürdigenZertifizierungsstellen. Der Browser findet im Windows-Zertifikatspeicherdas im vorherigen Schritt ausgestellte Zertifikat mitsamt dem privatenSchlüssel und verwendet es zur Authentifizierung am Server. Der ASABAP prüft nun, ob das Zertifikat vertrauenswürdig ist, dann wird der Be-nutzer anhand der Zuordnung des SAP-Benutzers zum Zertifikat in der Ta-belle USREXTID authentifiziert. Er ist nun am SAP-System angemeldet.

4.1.2 Systemvoraussetzungen

Für die Umsetzung des in diesem Workshop behandelten Szenarios werdendie in Tabelle 4.1 aufgeführten Systeme mit den entsprechend installiertenSoftwarekomponenten benötigt.


97


4.1.3 Konfigurationsschritte

Die Konfigurationsschritte dieses Workshops werden mit einem AS ABAP7.00 und Windows Server 2008 bzw. Windows 7 dokumentiert. Als Browserwird der Microsoft Internet Explorer verwendet (es kann jeder Browser, derden Windows-Schlüsselspeicher verwendet, genutzt werden).

Für jeden Domänenbenutzer, den Sie in diesem Szenario verwenden möch-ten, muss bereits ein passender SAP-Benutzer im SAP-System vorhandensein, z. B. tdcwdf09\johnd in der Domäne und »JOHND« im SAP-System.

Installation der Zertifizierungsstelle für Ihre Domäne

Um das Active Directory als Zertifizierungsstelle zu betreiben, müssen dieActive Directory Certificate Services installiert werden. Diese können unmit-telbar auf dem Domänencontroller oder auf jedem anderen Server derDomäne installiert werden.

1. Starten Sie den Server Manager auf dem Desktop, der zu Ihrer Zertifizie-rungsstelle werden soll. Den Server Manager finden Sie im Startmenü unterSettings � Control Panel � Administrative Tools � Server Manager.

System Software

Windows Active Directory/Zertifizierungsstelle

� Microsoft Windows Server 2008 Enterprise mit Active Directory

� Windows Server 2003 Enterprise mit Active Directory Services ab Schema Version 34

Desktops der Benutzer Microsoft-Desktop-Betriebssysteme wie

� Windows XP (ab Service Pack 2)

� Windows Vista

� Windows 7

SAP-System SAP NetWeaver AS ABAP 6.40 oder höher

Tabelle 4.1 Systemvoraussetzungen

Zertifikat-Enrollment mit Genehmigungsprozess

Im Workshop wird das Certificate Autoenrollment beschrieben. Dies bedeutet, dasszur Ausstellung bzw. Erneuerung eines Zertifikats keine Interaktion vonseiten desAdministrators bzw. des Benutzers erforderlich ist. Diese Schritte können jedoch auchmit Genehmigungsprozessen, z. B. durch einen Administrator, versehen werden.


98


2. Weisen Sie Ihrem Server die Rolle Active Directory Certificate

Services zu. Hierzu klicken Sie mit der rechten Maustaste auf den erstenUnterknoten mit dem Namen Roles und wählen Add Roles. In der Listeder verfügbaren Serverrollen wählen Sie Active Directory CertificateServices.

3. Betätigen Sie den Next-Button, um den Wizard zu starten, der Sie durchdie Installation führen wird.

4. Als Antwort auf die Frage nach den zu konfigurierenden Role Servicesmarkieren Sie nur die Checkbox vor Certification Authority.

5. Als Setup Type wählen Sie »Enterprise«; als CA Type wählen Sie »Root CA«.

6. Wählen Sie Create a new private key, um einen neuen asymmetrischenSignaturschlüssel für Ihre Zertifizierungsstelle zu erstellen. ÜbernehmenSie den Vorschlag des Wizards: cryptographic provider ist RSA#Micro-soft Software Key Storage Provider mit der Key Length 2048 und»sha1« als hash algorithm.

7. Übernehmen Sie den vorgeschlagenen Common Name samt dem Distin-guished-Name-Suffix. Der daraus resultierende Distinguished Name wirdin einem Feld darunter angezeigt. Dieser Name wird als Inhabername fürdas Signaturzertifikat der Zertifizierungsstelle verwendet und sollte diesein ihrem Unternehmen eindeutig identifizieren.

Der SHA256-Hash-Algorithmus

Der SHA256-Hash-Algorithmus wird von SAP-Systemen ab SAP CryptographicLibrary Version 1.555.29 unterstützt. Diese Version ist für SAP-Systeme ab demSAP-Basisrelease 7.02 verfügbar.

Zur Prüfung der Version Ihrer SAP Cryptographic Library starten Sie die TransaktionSTRUST und wählen sodann im Menü Environment � SSF Version Anzeigen aus.Das angezeigte Dialogfenster zeigt die Version der SAP Cryptographic Library.

Hinweise für die Installation in einer Produktivlandschaft

Mit der Bestätigung des nächsten Schritts, werden die AD CS in Ihrer Landschaftinstalliert. Je nach aktiver Gruppenrichtlinie in Ihrer Domäne ist damit auch dieAnwendung einiger Standardzertifikatvorlagen, wie z. B. die Verteilung des Wurzel-zertifikats auf die einzelnen Server in Ihrer Landschaft, verbunden. Für produktiveInstallationen sollten Sie nur die Zertifikatvorlagen freischalten, die Sie auch wirklichbenötigen.


99


Abbildung 4.2 Abschlussseite des AD-CS-Konfigurations-Wizards

Prüfen Sie, ob die von Ihnen vorgenommenen Einstellungen mit den inAbbildung 4.2 gezeigten Einstellungen übereinstimmen. Betätigen Sie nunden Button Install, um mit der Installation zu beginnen.

Zertifikatvorlage erzeugen

Die auszustellenden Benutzerzertifikate entsprechen einem bestimmtenMuster, der Zertifikatvorlage. Diese Vorlage beinhaltet Angaben zur Gültig-keitsdauer des Zertifikats, zum Format des Inhabernamens (Subject), zurSicherheit des privaten Schlüssels sowie zur Gestaltung des Ausstellungs- undErneuerungsprozesses des Zertifikats.

Fügen Sie den folgenden Eintrag in die Datei C:\Windows\CAPolicy.inf ein, um dasAnwenden der Standardzertifikatvorlagen zu unterdrücken:[certsrv_server]

LoadDefaultTemplates=0

Installation der AD CS unter Windows Server 2003 Enterprise Edition

Wechseln Sie zur Systemsteuerung, und starten Sie Add or Remove Programs.Wählen Sie zunächst Add/Remove Windows Components und anschließend Cer-tificate Services.


100


Führen Sie die folgenden Schritte aus, um die Zertifikatvorlage anzulegen:

1. Starten Sie die Certificate Templates Console auf dem Server, der imvorherigen Schritt als Zertifizierungsstelle eingerichtet wurde. Hierzu öff-nen Sie das Startmenü und wählen Run… In das erscheinende Textfeldgeben Sie »certtmpl.msc« ein und klicken anschließend auf OK (sieheAbbildung 4.3).

Abbildung 4.3 Verwaltungs-MMC für Zertifikatvorlagen

2. Legen Sie nun die Vorlage für das Autoenrollment von X.509-Zertifikatenan. Wählen Sie hierzu das existierende Template mit dem Namen »User«aus, drücken Sie die rechte Maustaste, und wählen Sie anschließend Dup-licate Template.

3. In dem nun erscheinenden Pop-up-Fenster wählen Sie Windows 2003 Ser-ver, Enterprise Edition und klicken anschließend auf OK.

4. Tragen Sie »User Auto Enrollment« als Wert in das Feld Template displayname auf dem Reiter General ein (siehe Abbildung 4.4); die anderen Vor-schlagswerte können übernommen werden. Setzen sie die Option Publishcertificate in Active Directory .

5. Die Vorschlagswerte im Reiter Subject Name können ebenfalls übernom-men werden (siehe Abbildung 4.5). Aus diesen Werten wird später derInhabername (Subject) des Zertifikats generiert. Achten Sie darauf, dassdie E-Mail-Adressen Ihrer Benutzer im Active Directory gepflegt sind.Andernfalls wird das Ausstellen der Zertifikate fehlschlagen.


101


Abbildung 4.4 Einstellungsmaske für die Zertifikatvorlage

Abbildung 4.5 Reiter »Subject Name«


102


6. Wechseln Sie in den Reiter Security, um sicherzustellen, dass die Domä-nenbenutzer die Berechtigung Autoenroll besitzen. Übernehmen Siedazu die Einstellungen aus Abbildung 4.6.

Abbildung 4.6 Autoenrollment-Berechtigungen für Domänenbenutzer

Der Inhabername und die Benutzerzuordnung im SAP-System

Bedenken Sie bei der Wahl des Subject-Name-Formats des Zertifikatnamens, dassSie diesen den SAP-Benutzern zuordnen müssen. In diesem Workshop dient die E-Mail-Adresse als gemeinsames Attribut zwischen dem Active Directory und demSAP-System. Im weiteren Verlauf des Workshops werden Sie noch erfahren, wie Siedie Zuordnung der Zertifikate zu den Benutzern in der Einzelpflege durchführen.

Einige allgemeine Hinweise zu möglichen Zuordnungsstrategien:

� Idealerweise kommt der SAP-Benutzername schon im Zertifikatnamen vor. Wennder sAMAccountName Ihrer Domänenbenutzer gleich dem Namen der SAP-Benutzer ist (, z. B. tdcwdf09\JOHND im Active Directory und Benutzer »JOHND«im SAP-System), wählen Sie Common Name als Subject-Name-Format. So kön-nen Sie im SAP-System eine Massenzuordnung mit dem Report RSUSREXT durch-führen (siehe Abschnitt 8.2.4). Der Report unterstützt auch die Implementierungeines BAdIs, mit dem es möglich ist, komplexere Zuordnungen abzubilden.

� Allerdings lässt sich die Microsoft-Seite auch anpassen. Mit einem eigenen Policy-Modul können Sie eigene Subject-Name-Formate für Ihre Zertifikate definieren.So ist es möglich, beliebige Benutzerattribute aus dem Active Directory im Zerti-fikatnamen zu speichern. Unter dem folgenden Link im Microsoft Technet findenSie weitere Informationen: http://tinyurl.com/adcspolmodules


103


Klicken Sie anschließend auf den OK-Button, um die Vorlage zu speichern.

Zertifikatvorlage freischalten

Schalten Sie die soeben erstellte Zertifikatvorlage frei, damit diese bei derAnwendung der Gruppenrichtlinie, die Sie im nächsten Schritt einrichtenwerden, von den Benutzer-Desktops verwendet wird.

1. Wechseln Sie nun in die Certificate-Authority-MMC, die Sie im Startmenüunter Settings � Control Panel � Administrative Tools � CertificationAuthority finden.

2. Erweitern Sie den Baum an dem Knoten, der den Namen Ihrer Zertifizie-rungsstelle trägt. Klicken Sie hierzu mit der rechten Maustaste auf Certifi-cate Templates. Im erscheinenden Kontextmenü klicken Sie sodann aufNew � Certificate Template to Issue. Das nun erscheinende Fenster sollteso aussehen wie in Abbildung 4.7.

Abbildung 4.7 Freischaltung von Zertifikatvorlagen

3. Wählen Sie die im letzten Schritt erstellte Vorlage mit dem Namen »UserAuto Enrollment«, und klicken Sie auf den OK-Button, um die Vorlage fürIhre Zertifizierungsstelle freizuschalten.

� Benutzerzuordnungen, die durch regelmäßig wiederkehrende Unternehmenspro-zesse, wie z. B. die Einstellung oder Umgruppierung von Mitarbeitern, ausgelöstwerden, können an zentraler Stelle mit SAP NetWeaver Identity Managementdurchgeführt werden.


104


Gruppenrichtlinie zur automatischen Verteilung von Benutzerzertifikaten

Nun geht es darum, die Desktops der Benutzer dazu zu bringen, Zertifikate aufBasis der soeben eingerichteten Vorlage anzufordern. Dazu müssen Sie dasAutoenrollment in Ihrer aktiven Gruppenrichtlinie für Ihre Domäne aktivieren.

1. Melden Sie sich als Domänenadministrator an Ihrem Domänencontrolleran.

2. Wechseln Sie in die Group-Policy-Management-MMC des Domänencon-trollers. Diese befindet sich im Startmenü unter Settings � Control Panel� Administrative Tools � Group Policy Management.

3. Starten Sie den Editor für die aktive Gruppenrichtlinie in Ihrer Domäne.Klicken Sie sich durch die Baumstruktur zum Eintrag Default DomainPolicy, klicken Sie anschließend mit der rechten Maustaste darauf, undwählen Sie Edit (siehe Abbildung 4.8). Ein neues Fenster mit dem Grup-penrichtlinien-Editor startet.

Abbildung 4.8 Starten des Gruppenrichtlinien-Editors

Die Zertifikatvorlage wird nicht angezeigt

Taucht Ihre Zertifikatvorlage für das Certificate Autoenrollment nicht in der Liste derverfügbaren Vorlagen auf, kann es sein, dass die Replikation über das Active Direc-tory noch eine Zeitlang andauert.

Ein anderer Grund könnte sein, dass die Active Directory Certificate Services nichtauf einer Windows Server Enterprise Edition installiert worden sind. Die Standarde-dition unterstützt beispielsweise nur das manuelle Enrollment von Zertifikaten, daseine Benutzerinteraktion erfordert.


105


4. Navigieren Sie zum Eintrag Public Key Policies, der sich im Baum unterUser Configuration � Policies � Windows Settings � Security Settingsbefinden (siehe Abbildung 4.9).

Abbildung 4.9 Aktivierung des Autoenrollments von Zertifikaten

5. Klicken Sie doppelt auf den Eintrag Certificate Services Client – Auto-Enrollment im rechten Abschnitt der Maske, woraufhin ein neues Pop-up-Fenster erscheint.

6. Stellen Sie Configuration Model auf Enabled, und aktivieren Sie diebeiden Checkboxen, die darunter sind.

7. Betätigen Sie den OK-Button, um die Änderungen an der Gruppenrichtli-nie in der Domäne zu aktivieren.

Die Konfiguration auf der Windows-Seite ist jetzt abgeschlossen. Meldet sichein Benutzer an seinem Desktop an, so erhält er automatisch ein Zertifikatvon der Zertifizierungsstelle, das er in seinem Browser verwenden kann.


106


Test, ob das Certificate Autoenrollment erfolgreich war

War die Verteilung der Benutzerzertifikate erfolgreich, wird für jeden Domä-nenbenutzer ein Zertifikat in der Windows-Zertifikatverwaltung des jeweili-gen Desktops gespeichert. Mithilfe des Certificate Snap-ins der MicrosoftManagement Console können Sie das überprüfen:

1. Melden Sie sich mit einem Domänenbenutzer an einem Desktop inner-halb Ihrer Domäne an.

2. Starten Sie das Certificate Snap-in. Hierzu öffnen Sie das Startmenü undwählen Run… In das nun erscheinende Textfeld geben Sie »certmgr.msc«ein und klicken anschließend auf den OK-Button.

3. Klappen Sie den Baum auf, und wählen Sie Certificates – Current User �Personal � Certificates aus.

4. Im rechten Teil des Fensters sollte nun ein Zertifikat zu sehen sein, das inder Spalte Issued By den Namen Ihrer Zertifizierungsstelle trägt. In derSpalte Certificate Template sollte »User Auto Enrollment«, der Name derverwendeten Zertifikatvorlage, genannt sein.

Sieht Ihr Bildschirm so wie in Abbildung 4.11 aus, haben Sie das CertificateAutoenrollment erfolgreich eingerichtet. Sollte dies nicht der Fall sein, müs-sen Sie nach der Problemursache suchen (siehe Abschnitt 4.1.5, »Fehlerana-lyse und -behebung«).

Abbildung 4.10 Zertifikat, das per Autoenrollment ausgestellt wurde


107


SSL-Konfiguration des SAP-Systems

Das SAP-System muss für die Verwendung des SSL-Protokolls konfiguriertsein. Bei der Authentifizierung mit Endbenutzerzertifikaten werden dieBenutzer am SAP-System über das SSL-Protokoll authentifiziert. Daher wer-den für die Kommunikation zwischen dem Webbrowser und dem AS ABAPHTTPS-Verbindungen benötigt.

Folgende Konfigurationsschritte sind notwendig, um die Verwendung vonX.509-Zertifikaten in Verbindung mit SSL auf Ihrem AS ABAP zu konfigurieren:

1. Setzen Sie den Parameter icm/HTTPS/verify_client im Default-Profil desAS ABAP über die Profilpflege, Transaktion RZ10, auf den Wert »1« (sieheAbbildung 4.12).

Abbildung 4.11 Profilparameterpflege

Bedeutung der Profilparameterwerte

Der Profilparameter icm/HTTPS/verify_client kann folgende Werte annehmen:

� 0 – Zertifikate ignorieren: Der Browser schickt für die SSL-Verbindung kein Zertifikat.

� 1 – Zertifikate akzeptieren: Der Browser kann für die SSL-Verbindung ein X.509-Zertifikat schicken.

� 2 – Zertifikate fordern: Der Browser muss für die SSL-Verbindung ein Zertifikat schicken.


108


2. Der Internet Communication Manager (ICM) empfängt und versendetAnfragen über HTTPS. Wechseln Sie zur Transaktion SMICM. Starten Sieden ICM neu, damit die SSL-Konfigurationseinstellungen übernommenwerden (siehe Abbildung 4.12).

Abbildung 4.12 Neustart des Internet Communication Managers

Vertrauensbeziehung zur Zertifizierungsstelle einrichten

Damit das SAP-System den Zertifikaten Ihrer Zertifizierungsstelle vertraut,müssen Sie das Wurzelzertifikat Ihrer Zertifizierungsstelle in das SAP-Systemimportieren.

1. Exportieren Sie zunächst das Wurzelzertifikat aus Ihrer Zertifizierungs-stelle. Hierzu wechseln Sie über den Pfad Start-Menü � Settings � Cont-rol Panel � Administrative Tools � Certification Authority erneut indie Certificate-Authority-MMC.

2. Klicken Sie mit der rechten Maustaste auf den Namen Ihrer Zertifizie-rungsstelle, und wählen Sie Properties im Kontextmenü.

3. Wechseln Sie in den Reiter General (siehe Abbildung 4.13), und drückenSie den Button View Certificate. Daraufhin werden die Eigenschaften desStammzertifikats in einem Pop-up-Fenster angezeigt.

4. Wechseln Sie zum Reiter Details, und betätigen Sie den Button Copy toFile.

5. Im sodann erscheinenden Certificate-Export-Wizard wählen Sie Base-64als Exportformat und speichern das Zertifikat ab.

Initiale SSL-Konfiguration

Wenn Sie noch kein SSL auf Ihrem SAP-System eingerichtet haben, folgen Sie derAnleitung in der offiziellen SAP-Dokumentation unter http://tinyurl.com/ABAP700ConfigureSSL


109


Abbildung 4.13 Globale Einstellungen der Zertifizierungsstelle

Nun importieren Sie das Wurzelzertifikat der Zertifizierungsstelle in das SAP-System, um die Vertrauensbeziehung herzustellen:

1. Melden Sie sich zunächst als Benutzer mit Administrationsberechtigungenan Ihrem SAP-System an.

2. Starten Sie nun die Transaktion STRUST, und doppelklicken Sie anschlie-ßend auf den Eintrag SSL Server Standard in der Baumstruktur.

3. Importieren Sie nun das Wurzelzertifikat, indem Sie im Menü Certificate� Import auswählen. Als File Format geben Sie Base-64 an. Wenn das Zer-tifikat gelesen werden konnte, wird es im unteren rechten Bereich ange-zeigt (siehe Abbildung 4.14).

Serverspezifische SSL-Zertifikate

Das SAP-System im Workshop verwendet für alle Applikationsserver ein Zertifikat,das von der Transaktion STRUST auf die PSEs (Personal Security Environment) dereinzelnen Instanzen verteilt wird. Falls Ihr System serverspezifische PSEs verwendet,müssen Sie den jeweiligen Applikationsserver im Baumknoten unterhalb der SSL-Server-Standard-PSE auswählen.


110


Abbildung 4.14 Import des Stammzertifikats in die SSL-Server-PSE

4. Klicken Sie nun auf Add to Certificate List, um das Zertifikat in die Listeder vertrauenswürdigen Zertifikate aufzunehmen. War der Import erfolg-reich, wird eine Erfolgsmeldung angezeigt.

5. Klicken Sie anschließend auf das Speichern-Symbol (Tastenkombination(Strg) + (S)), um die Änderungen in der SSL-Server-PSE zu sichern. Wennder Speichervorgang erfolgreich war, wird eine Erfolgsmeldung angezeigt.

6. Je nach Release werden Sie in der Meldung dazu aufgefordert, den ICMneu zu starten. Ab Release 7.10 wird der ICM automatisch über Änderun-gen an der Server-PSE unterrichtet, so dass Sie ihn nicht manuell neu star-ten müssen.

7. Wechseln Sie in die Transaktion SMICM und wählen Sie den MenüpfadAdministration � ICM � Exit Soft � Local, um den ICM neu zu starten.

Zuordnung der Zertifikate zu den Benutzern im SAP-System

Die Zuordnung des Benutzerzertifikats zum SAP-Benutzer wird in der TabelleUSREXTID gepflegt.

In diesem Workshop beschränkt sich die Beschreibung auf die Einzelpflege;es werden zwei Alternativen beschrieben:


111


� Pflege durch den Administrator via Transaktion EXTID_DN

� Pflege durch die Benutzer selbst mit dem CERTMAP-Service (ab AS ABAP6.20)

Pflege durch den Administrator via Transaktion EXTID_DN

Bei der ersten Option gehen Sie folgendermaßen vor:

1. Exportieren Sie das Benutzerzertifikat aus dem Certificate Snap-in in eineDatei. Klicken Sie hierzu mit der rechten Maustaste auf das Zertifikat, undwählen Sie All Tasks � Export… (siehe Abbildung 4.15).

Abbildung 4.15 Export des Benutzerzertifikats

2. Im erscheinenden Certificate-Export-Wizard wählen Sie No, do not ex-port the private key und drücken anschließend den Next-Button. Imnächsten Schritt wählen Sie Base-64 als Exportformat und speichern dasZertifikat.

3. Melden Sie sich nun als Benutzer mit Administrationsberechtigungen anIhrem SAP-System an, und starten Sie die Transaktion EXTID_DN.

4. Wählen Sie den Eintrag New Entries aus der Knopfleiste (siehe 1 in Ab-bildung 4.16).

5. Im sodann erscheinenden Bildschirm wählen Sie das Symbol zum Importvon Dateien auf der Höhe des Feldes External ID 2. Navigieren Sieanschließend zum Ablageort des zuvor gespeicherten Benutzerzertifikats,und markieren Sie es. Drücken Sie schließlich den Open-Button.


112


Abbildung 4.16 Import des Benutzerzertifikats mit der Transaktion EXTID_CN

6. Das Zertifikat wurde jetzt analysiert. Im Feld External ID sollte der Namedes Zertifikats stehen (siehe Abbildung 4.17). Das Feld Issuer sollte denNamen Ihrer Zertifizierungsstelle enthalten.

Abbildung 4.17 Die fertige Zuordnung


113


7. Pflegen Sie nun die Zuordnung des Zertifikats zum SAP-Benutzer. TragenSie hierzu den SAP-Benutzernamen in das Feld User ein, und aktivierenSie die Checkbox Activated.

Speichern Sie Ihre Zuordnung über die Tastenkombination (Strg) + (S).

Pflege durch die Benutzer selbst via CERTMAP-Service

Geben Sie Ihren Benutzern die folgende Anleitung zur Hand, damit sie IhreZertifikatzuordnung eigenständig pflegen können:

1. Starten Sie den Internet Explorer, und öffnen Sie den CERTMAP-Service.Die Adresse setzt sich folgendermaßen zusammen:https://<app server host>:<https-port>/sap/bc/bsp/sap/certmap.

2. Je nach Konfiguration Ihres Internet Explorers werden Sie dazu aufgefor-dert, ein Benutzerzertifikat anzugeben (siehe Abbildung 4.18). Wählen Siedas Zertifikat aus, das Sie Ihrem SAP-Benutzer zuordnen möchten. WennSie keine Aufforderung erhalten, hat Ihr Browser das Benutzerzertifikatautomatisch mitgeschickt.

Abbildung 4.18 Auswahl des Zertifikats, das zugeordnet werden soll

3. Geben Sie nun Ihren SAP-Benutzernamen und Ihr Passwort ein (siehe Ab-bildung 4.19), damit das System das zuvor gewählte Zertifikat Ihrem SAP-Benutzer zuordnen kann.


114


4. Überprüfen Sie die sodann angezeigten Daten auf dem Bildschirm (sieheAbbildung 4.20).

Abbildung 4.19 Anmeldung am SAP-System

Drücken Sie anschließend auf den Yes-Button, um die Zuordnung IhresBenutzerzertifikats zu Ihrem SAP-Benutzer abzuschließen.

Abbildung 4.20 Zuordnung des Benutzerzertifikats

4.1.4 Szenario testen

Nachdem nun auch das SAP-System fertig eingerichtet worden ist, kann dasSzenario getestet werden:

1. Melden Sie sich an einem Windows Desktop mit einem Domänenbenut-zer an und öffnen Sie den Microsoft Internet Explorer.

2. Geben Sie die Adresse des ITS-Service webguis Ihres Systems an. DieAdresse setzt sich folgendermaßen zusammen:https://<app serv. host>:<https-port>/sap/bc/gui/sap/its/webgui.Wenn Sie gefragt werden, welches Zertifikat Sie zur Authentifizierungbenutzen möchten, wählen Sie das Zertifikat, das per Autoenrollment aus-gestellt wurde.


371

Index

.NETInstallation 298Passport 35, 76

.Net (WS-Consumer)Fehleranalyse 287

A

Access Control List � ACLAccount Linking 27, 31, 45, 57, 188,

219ACL 181Active Directory 142, 147, 187

Authentication Service 96Domäne 89, 90, 94Domänencontroller 89, 104, 187gpresult.exe 115Group Policy 104Group Policy Management 104Group Policy Management Editor 104Gruppenrichtlinie 95, 104, 105, 115Gruppenrichtlinien-Editor 104SAM-Account-Name 102, 305Schema-Snap-in 191

Active Directory Certificate Services � AD CS

Active Directory Federation Services 2.0 � ADFS 2.0

AD CS 89, 94, 97Certificate Autoenrollment 95, 96, 100Certificate-Authority-MMC 103Policy-Modul 102Subject-Name-Format 102Zertifikatvorlage 99, 103

ADFS 2.0 187, 295Claim 297, 298Claim Rule 202Custom Rule 204Download 298Managementkonsole 201NameID-Claim 310Relying Party 298, 318Relying Party Identifier 304, 318

Advanced Encryption Standard 140Anmelde-Cookie 41

ApacheAxis2 255Rampart 255Tomcat 259WSS4J 257

A-priori-Provisioning 32Arbeitserleichterung 22asymmetrischer Schlüssel 67asymmetrisches Schlüsselpaar 96Attribute Query 51Attribute Statement 48Authentication Query 51Authentication Request Protocol 50Authentication Service 70Authentication Stack 148, 182, 226

Ticket 182, 226Authentication Statement 47Authentifizierung 22, 248

nachrichtenbasierte 244, 335Authentifizierungsattribut 31Authentifizierungsverfahren 44Authorization Decision Query 51Authorization Decision Statement 48Axis2

axis2.xml 263ConfigurationContext 262crypto.properties 265Proxy-Generierung 258, 261SAML 255saml.properties 264X.509-Authentifizierung 291

Axis2 (WS Consumer)Fehleranalyse 269

B

BasicPasswordLoginModule 182Bearer 63Beispielanwendung

InventoryClient (WS-Consumer Metro) 293

InventoryWebClient (WS-Consumer .Net WCF) 287

InventoryWebClient (WS-Consumer EE5) 283


372

Index

Beispielanwendung (Forts.)InventoryWebClient (WS-Consumer

Metro) 279InventoryWebClient (WS-Consumer-

Axis2) 268Microsoft Excel 313

BenutzerDELAY_L_ 243DELAY_LOGON 243virtueller 162

Benutzerabbildung 58, 147, 162, 175, 199, 229

Benutzeradministration 165Benutzerprofilattribut 31Benutzerzertifikat 39, 93, 110, 113Berechtigungsattribut 31Binding 52Business Process Management 321

Aktivität 322Automated Activity 323, 324, 333, 359BPM-Prozess 321, 323Deployment 335Fehleranalyse 359Human Activity 323Lane 323Laufzeitverhalten 325logischer Port 350, 351Pool 322Portalrolle 329Potential Owners 323, 334Principal Propagation 323, 327, 334SCA-Datei 327, 330, 331Service Group 333Servicedefinition 347Servicegruppe 350Service-Interface-Definition 333Sicherheitsanforderung 324Test 354Testdaten 355Universal Worklist 325, 328Webservice Binding Information 347Webservice-Endpunkt 347

Business Role 188Business Server Page 170Business to Business 159

C

Calculated Roles 171Certificate Autoenrollment 96Certificate Snap-in 106, 111CERTMAP-Service 111, 113Claim 298

NameIdentifier-Claim 297, 304Clock Skew 185Communication Channel 313Config Tool 223Cookie 42

Domain 43CreateTicketLoginModule 182Cross-Domain-SSO 45

D

Defederation 229De-Provisioning 33Diffie-Hellman-Verfahren 79, 218digitale Signatur 36digitales Zertifikat 36

E

EclipseApache Axis2 konfigurieren 259Axis2-WS-Consumer 258

Enterprise Portal Archive 170ERP 6.0 162Erstanmeldung 23EvaluateTicketLoginModule 182External

ID USREXTID 111EXTID_DN 111

F

Federation Termination 229Fehleranalyse

.Net (WS-Consumer) 287Axis2 (WS-Consumer) 269JAX-WS (WS-Consumer) 283Metro (WS-Consumer) 279, 294MS Office (WS-Consumer) 317OpenID 230SAML-Web-SSO 184, 211SOA Manager 365


373

Index

Fehleranalyse (Forts.)SPNEGO 152SRT_UTIL 365

Firefox 74, 151Firewall 61Föderation 45FQDN 171Fully Qualified Domain Name � FQDN

G

Generic Security Service Application Pro-gram Interface � GSS-API

GlassFishMetro 270

GSS-API 74, 89

H

Hash-Funktion 36Holder-of-Key-Variante 67, 69HTTP

Basic Authentication 44Callbacks 217Client 217Proxy 227Redirect 55Service-Baum 210Sicherheits-Session-Management 195

HttpWatch 43, 75

I

IAIK 217IAIK Cryptography Library 218ICF 83, 210ICM 108, 171Identität 23Identitäts- und Authentifizierungsdaten

transferierbare 26Identitätsattribut 31Identitätsverbund 29

länderübergreifender 29Identitätsverwaltung 30Identity Federation Framework 44Identity Management 30

System 32Identity Propagation 64Identity Provider � IdP

Identity Provisioning 32, 188Identity Store 192IdP 23, 161, 163IIS 314Incident 231Inclusive Namespaces 275Initial Load 192Integrated Windows Authentication �

IWAIntegration Builder 312intermediär 65Internet Communication Framework �

ICFInternet Communication Manager �

ICMInternet Information Services Manager �

IISInteroperabilität 28Inventory Service 241Issuer

USREXTID 112ITS-Service webgui 114iView 170IWA 76, 190, 196, 207

J

JAAS 59, 181Service Provider Interface 181

JAAS-Authentication-Framework 216Java Authentication and Authorization

Service � JAASJava Cryptography Extension � JCEJava-Schlüsselpaar

Erzeugen 246JavaScript 55JAX-WS

Handler 281Handler einbinden 282SAML 280WS-Consumer 277

JAX-WS (WS-Consumer)Fehleranalyse 283

JCE 146Job Log 206Just-in-Time-Provisioning 33


374

Index

K

Kerberos 70, 89, 139Key Distribution Center 70, 89, 153,

294MIT Kerberos 91Principal 70, 294Principal Name 71, 140, 142Realm 71, 145Service Principal Name 71, 142Serviceticket 72, 90, 141STS 296Ticket Granting Service 72Ticket Granting Ticket 71, 90, 141

Kerbtray 72, 154Key Storage 163

L

länderübergreifender Identitätsverbund 29

Liberty Alliance 35Linux 91Logging 230Login-Modul 181

Flag 183Logon Procedure 201Logon UI Application 216Logon-Alias 147, 200Logon-ID 147, 189, 200

M

Message Authentication Code 36Metro 270

SAML 271WSIT 270X.509-Authentifizierung 290

Metro (WS-Consumer)Fehleranalyse 294

Microsoft Developer Network � MSDNMicrosoft Excel-Plug-in 296Microsoft Technet 102, 116MS Office (WS Consumer)

Fehleranalyse 317MSDN 319MYSAPSSO2 42

N

nachrichtenbasierte Authentifizierung 244, 335

NetBeans IDE 271NetWeaver Administrator � NWANetWeaver Business Client 200Network Time Protocol 185NTLM 76NWA 163

O

OASIS 44OASIS WS-Trust 1.3 295OpenID 76, 215

Association 79, 227Authentication Request 79, 227Authentication Response 80, 228Discovery Request 79, 227Discovery Response 79Fehleranalyse 230Foundation 77Identität 77Projekt importieren 221Provider 77, 215, 218

OpenID-Login-Modul 217Subkomponenten 217

P

Phishing 80PKCS#8 165Portalrolle 170Principal (Java) 275Privilege 188Profile 53Profilparameter

login/password_change_for_SSO 207Proof Token 68Protection Assertions 69Protocol 50PSE

STRUST 110System 180, 340

Pseudonym 48, 161persistentes 57transientes 161, 171, 174, 204

Public Key Infrastructure 39


375

Index

R

Rampart konfigurieren 262Referenzbenutzer 177Relying Party 24Remote Procedure Call 61Replay-Attacke 44Report

RSUSREXT 102, 249, 250, 354Z_SAML_TRUST 250

Repository 192Request Security Token � RSTRequest Security Token Response �

RSTRRisiko 22RST 67RSTR 68RSUSREXT 200, 310

X.509 292

S

SAM-Account-Name 189, 310SAML 35, 44

1.x 452.0 45Artifact 56Assertion 46, 326Assertion Authentication Statement 326Assertion Consumer Service 53Assertion NameIdentifier 326Attester 338, 342, 344Attribut 174, 297Authentication Context 50, 169, 196Authentication Request 209AuthnRequest 50, 212Backchannel 56Binding 52, 169CallbackHandler (Metro) 275CallbackHandler (WSS4J) 265Common Domain Cookie 53Configuration 201Confirmation Method 63E-Mail-Adresse 252Holder-of-Key 66Holder-of-Key (WS-Provider) 288Kerberos-Name 252Konzept 46NameIdentifier 310

SAML (Forts.)NameID-Format 171Namenskennung 252persistent 253Profile 46, 53Request 50Response 50, 212SAML 1.0-Token 295SAML 2.0-Token 295saml_default_attester 338, 351Sender-Vouches 64Standardbestätiger 341Statement 47Subject 46, 47symmetrischer Schlüssel 296Token 326Token Profile 62, 321, 325, 327Token-Aussteller 338transient 253Unspecified 252Web Application Policy 201, 209Webservices 60Windows-Name 252WS-Federation-Metadaten 168, 173,

197, 251, 299, 306, 341, 342, 344WS-Föderation-Metadaten 58X.509-Subject Name 252

SAML2Aktivierung 343Einrichtungsassistent 163Web Service Policy 306

SAML2LoginModule 182saml2-Service 196SAP Community Network 77, 218SAP Cryptographic Library 217, 242SAP Developer Network � SDNSAP GUI 83, 89SAP Java Cryptographic Toolkit 217SAP Logon Ticket 42, 170, 175

Legacy Systems Support 179SAP Management Console 222SAP NetWeaver Business Process

ManagementAutomated Activity 333

SAP NetWeaver Developer Studio 221SAP NetWeaver Identity Management

103, 187Identity Center 191

SAP NetWeaver PI 312


376

Index

SAP Provisioning Framework 192SAP Trust Center Service 118

Benutzerzertifikat 120Berechtigung 132CERTRQ 125Distinguished Name 124Endbenutzerzertifikat 137Konfigurationsschritt 120Kundenmeldung 129Profilparameter 121, 123Registrierungsstelle 118SAP Passport 118, 119SSF 125SSFA 126SSF-Anwendung 126SSF-Anwendungs-PSE 128SSFAPPLIC 125Systemvoraussetzung 120Trust Manager 122USREXTID 120, 136Wurzelzertifikat 122, 123Z_CERTREQ 132, 133Zertifikatanforderung 129Zertifikatanforderungsservice 134Zertifikatantrag 118, 119Zertifikatantragsservice 118Zertifikatantwort 130, 131Zertifizierungsstelle 118

Schlüsselasymmetrischer 67privater 93symmetrischer 67

Schlüsselmanagement 69Schlüsselpaar

asymmetrisches 96Schlüsselpaar erzeugen 246, 248SDN 319Secret Key 36Secure Network Communication 83Secure Network Connection � SNCSecure Sockets Layer � SSLSecurity Assertion 23Security Assertion Markup Language �

SAMLSecurity Binding Assertions 70Security Token 24, 61Security Token Service � STSSecurity Troubleshooting Wizard 155,

185, 230, 359

Semantik 28Serverzertifikat 39Service Principal Name 143Service Provider � SPSeverity 231SHA1 301SHA256 301SHA256-Hash-Algorithmus 98Sicherheitsanforderung 42Sicherheitsgewinn 22Sicherheitskonzept 36Signatur

digitale 36Single Logout 45, 173SNC 89SOAP 61

Fault 61SP 24, 161

lokale Konten 32SPNEGO 74, 139

Login-Modul 139, 148MechToken 75MechType 75NegTokenInit 75NegTokenTarg 75

SSL 40, 93, 95, 107, 293Konfiguration im AS ABAP 107Serverzertifikat 279WS-Consumer (Axis2) 268WS-Consumer (GlassFish) 279

SSL-Serverzertifikat 247SSO im Internet 35SSO mit Zertifikat 40SSO-Technologie

Anforderung 25Chancen und Risiken 22im Unternehmen 26verwandte Konzepte 21zwischen Unternehmen 27

STS 24, 295Sun GlassFish

Applikationsserver 273Sun Metro 270Supporting Token Assertions 70SvcTraceViewer.exe 319symmetrischer Schlüssel 67


377

Index

T

TabelleUSREXTID 95, 110, 326, 345, 352,

360, 361technische und organisatorische Restrikti-

onen 27Telnet 222TicketKeystore 180TLS � SSLToken Assertions 70Trace Location 231Traces 186, 212Tracing 230Transaktion

ME23N 357PFCG 132RZ10 121RZ11 207SA38 309SAML2 197, 211, 251, 299, 342, 343SE16 125SE38 336SICF 134, 196, 210SIFC_SESSIONS 195SM50 212SM51 212SMICM 122, 171SOAMANAGER 244, 271, 311, 346SRT_UTIL 318SRTUTIL 359, 361SSFA 125STRUST 109, 122, 130, 278, 292, 340STRUSTSSO2 180SU01 177, 206, 330

transferierbare Identitäts- und Authentifi-zierungsdaten 26

Trusted Provider 173

U

UME 229Attribut 219Eigenschaft 176, 181

USREXTID 188, 200

V

Verfügbarkeit 23Vertrauensbeziehung 26, 29, 41, 173,

180, 336, 338SAML2 251

Vertrauensbeziehung einrichten 248virtueller Benutzer 33, 162virtuelles privates Netzwerk 27

W

WCFSAML 283, 295

Web Diag Tool 155, 232Web Services Security 60Web Services Security Policy 69Web SSO 45Webservices 60Windows Communication Framework

319Windows Live ID 76Windows Server 2008

Server Manager 97Serverrolle 94, 98

Windows-SchlüsselpaarErzeugen 248

Windows-Zertifikatspeicher 89, 96, 97Windows-Zertifikatverwaltung 106Wireshark 152Workshop

Single Sign-on mit SPNEGO 139World Wide Web 35WS Metadata Exchange 309WSDL

NetBeans 272ohne WS-Policy 258WS-Policy 296

WSDL2Java 261WS-Metadata-Exchange 296, 306WS-Policy 69WSS_SETUP 335, 337

Validierung SAML 1.1 251WSS4J

Konfiguration 264, 283WS-SecurityPolicy

IssuedToken-Assertion 296WS-Trust 24, 67


378

Index

Wurzelinstanz 40Wurzelzertifikat 108, 300

X

X.509 38Authentifizierung 290

XACML 52, 59XML 61

Signatur 61Verschlüsselung 61

Z

Zertifikat 38, 89, 93, 164digitales 36Erneuerung 99Inhabername 98, 99, 100selbst signiertes 40Verteilung 93vertrauen 93Zertifikatantrag 96

Zertifikatantrag 96Zertifikatkette 40Zertifizierungsstelle 38, 93, 94, 95, 96,

300, 314


Single Sign-on mit SAP

Documents

Transcript of Single Sign-on mit SAP