Voraussetzungen:
Der Simplifier SSO-Mechanismus verwendet die SAP-Standardberechtigungen und bereits zugewiesenen SAP-Rollen.
- Lesezugriff auf Daten, d. h. es muss sichergestellt sein, dass der Aufrufer die erforderlichen Berechtigungen besitzt, und
- Änderungen müssen revisionssicher sein, d. h. es muss möglich sein, nachzuvollziehen, wer Änderungen an Daten initiiert hat.
Funktionierender Identity Provider
Dieses SAP Single Sign-On-Szenario funktioniert mit allen SAML 2.0-unterstützten Identity Providern, wie:
- onPremise Azure Active Directory über ADFS
- Azure Active Directory
- Google über SAML
- und viele mehr
Single Sign-On mit SAML Sender Vouches zwischen Simplifier und SAP Application Server ABAP 7.x
Das folgende Bild veranschaulicht den Single Sign-On-Mechanismus:
Wie funktioniert es?
Der Benutzer fordert die Anmeldung mit einem Client (Browser oder Simplifier Mobile Client App) in einer Simplifier-Anwendung unter Verwendung des vorkonfigurierten Identity Providers über SAML 2.0 an.
Der Identity Provider zeigt seine Anmeldeseite an, und der Benutzer kann authentifiziert werden. Nach der Autorisierung wird der Benutzer zurück zur Simplifier-Anwendung geleitet, und der Simplifier speichert den bereitgestellten Sicherheitsschlüssel in einem gesicherten Key-Vault-Speicher (SAML-Assertion).
Wenn eine SOAP-Anfrage von der Simplifier-Anwendung ausgeführt wird, fügt der Simplifier selbst den Sicherheitsschlüssel hinzu, signiert die vollständige Anfrage – einschließlich der Daten – mit einem Zertifikat und sendet sie an das SAP-Backend. Simplifier agiert daher in der Rolle eines Security Token Service.
SAP Enterprise Webservices, die von Simplifier SOAP Konnektoren angesprochen werden, empfangen Nachrichten über das Internet Communication Framework (ICF), das die HTTP-Anfragen empfängt und einen AS ABAP-Workprozess zu deren Verarbeitung zuweist. Alle vom ICF unterstützten Authentifizierungsmethoden basieren auf Übertragungen auf SSL-Protokollebene oder als HTTP-Header. Im Falle einer nachrichtenbasierten Anmeldung, z. B. über Benutzername-Token, SAML-Token oder X.509-Zertifikat, sind die Daten nicht Teil eines HTTP-Headers, sondern befinden sich in einem SOAP-Header, auf den das ICF keinen Zugriff hat. Daher ist keine direkte Anmeldung möglich, sondern das ICF führt zuerst eine Anmeldung mit einem technischen Benutzer durch (z. B. DELAY_LOGON). Nach erfolgreicher Sicherheitsverarbeitung wird eine Benutzeränderung gemäß der konfigurierten Authentifizierung durchgeführt.
Schritt 1 – SAP Cryptographic Library prüfen
Die für WS-Security erforderlichen RSA-Signaturen und Verschlüsselungsfunktionen sind in einer separaten Bibliothek verfügbar, der SAP Cryptographic Library, die über den SAP Service Marketplace bezogen werden kann. Informationen zum Bezug dieser Bibliothek finden Sie im SAP-Hinweis 397175.
Die Bibliothek muss in der Version “SSFLIB Version 1.555.24 ; SECUDE(tm) SAPCRYPTOLIB” oder höher verfügbar sein.
Gehen Sie zur Transaktion STRUST und wählen Sie im Menü Umgebung -> SSF-Version anzeigen
Schritt 2 – Webservice-Sicherheitseinrichtung prüfen
Jede nachrichtenbasierte Authentifizierung wird technisch durch die Änderung des Benutzers DELAY_L_ durchgeführt<SID> (Releases 7.0X) oder DELAY_LOGON (Releases 7.10 und höher) zu dem durch den Sicherheitsheader authentifizierten Benutzer.
Der DELAY_L_<SID>/DELAY_LOGON-Benutzer wird durch den Report wss_setup erstellt, und der Benutzername und das Passwort werden im sicheren Speicher des Systems gespeichert. Um den Benutzer zu erstellen, müssen die folgenden Voraussetzungen erfüllt sein:
- Das System muss die Anmeldung mit Benutzername und Passwort zulassen. Wenn die passwortbasierte Anmeldung im System generell deaktiviert ist, muss der Benutzer DELAY_LOGON in einer Gruppe enthalten sein, die die passwortbasierte Anmeldung zulässt.
- Für Systeme, die Teil einer zentralen Benutzerverwaltung (ZBV) sind, muss sichergestellt sein, dass die Generierung von Benutzern in ZBV-Kindsystemen zulässig ist.
Um den Benutzer DELAY_LOGON zu generieren, führen Sie bitte den Report WSS_SETUP über die Transaktion SA38 aus.
Bitte beachten Sie, dass der TEST-Modus nicht aktiv ist.
Um den Report auszuführen, drücken Sie F8.
Schritt 3 – SAP Webservice einrichten
Die SAP Webservices werden über die Transaktion SOAMANAGER konfiguriert. Führen Sie die folgenden Schritte aus, um eine Konfiguration für die SAML-Authentifizierung für jeden einzelnen Webservice zu erstellen:
Schritt 3-1 – SOA Manager öffnen
Führen Sie die Transaktion SOAMANAGER aus, woraufhin das System einen neuen Browser-Tab startet. Wählen Sie nun Web Service Configuration im Service Administration Tab aus.
Schritt 3-2 Betroffenen Webservice auswählen
Suchen Sie nach dem Web Service und wählen Sie diesen durch Klicken auf den Link in Schritt 2 unten aus:
Schritt 3-3 Service Endpoint erstellen
Wählen Sie Service erstellen, um eine neue Konfiguration zu erstellen.
Schritt 3-4 Binding Name konfigurieren
Konfigurieren Sie einen technischen Namen und einen Binding Name (kann derselbe sein) für die Webservice-Definition
Schritt 3-5 Provider Security konfigurieren
Um die Nachricht für die Transportsicherheit zu verschlüsseln, wählen Sie HTTPS als Transportgarantietyp aus. Setzen Sie Message Level Security auf “None”. Für Single Sign-On über SAML Sender Vouches wählen Sie Single Sign-On with SAML als Authentifizierungsmethode aus.
Schritt 3-7: SOAP-Protokoll konfigurieren
In diesem Schritt können Sie die Standardeinstellungen wie unten beschrieben beibehalten
Schritt 3-8 Operation Settings konfigurieren
In diesem Schritt können Sie die Standardeinstellungen wie unten beschrieben beibehalten und die Einrichtung des Webservices abschließen
Schritt 4 Zertifikat für Security Token Service installieren
Für den Signierungsprozess der SOAP-Anfrage benötigen Simplifier und SAP eine vertrauenswürdige Beziehung.
Daher benötigen Sie ein gültiges Zertifikat mit einer Signierungsfunktion, die von beiden Systemen (Simplifier und SAP) erkannt wird.
Schritt 4-1 Self-Sign-Zertifikat generieren
In diesem Artikel verwenden wir ein Hilfstool namens mkcert, um den Prozess zu vereinfachen. Sie können mkcert hier herunterladen.
Nach der Installation des mkcert-Tools generieren Sie ein neues Zertifikat:
mkcert simplifier@myenterprise.com
Schritt 4-2 Generiertes Zertifikat verifizieren
Bevor Sie das Zertifikat in Simplifier und SAP hochladen, sollten Sie prüfen, ob das Zertifikat in der Lage ist, digitale Entitäten zu signieren.
openssl x509 -in simplifier@myenterprise.com.pem -noout -text
Das Validierungsergebnis sollte die Option “Digital Signature” anzeigen.
Schritt 4-3 Generiertes Zertifikat in SAP hochladen
Um Ihr Zertifikat hochzuladen, benötigen Sie die Berechtigung für die Transaktion STRUST. Starten Sie die Transaktion STRUST und wechseln Sie in den Änderungsmodus
Klicken Sie auf der linken Seite auf den Ordner WS Security WS Security Keys und importieren Sie die öffentliche Zertifikatsschlüsseldatei (*.pem) von Ihrem lokalen Client
Nachdem Sie die Zertifikatsinformationen überprüft haben, müssen Sie das Zertifikat zur Zertifikatsliste hinzufügen
Klicken Sie auf die Schaltfläche Speichern, um den Upload-Vorgang abzuschließen.
Schritt 5 Vertrauenswürdige Beziehung herstellen
Die Authentifizierung einer SAML-Assertion erfordert eine vertrauenswürdige Beziehung zwischen Simplifier und SAP. Daher müssen Sie Simplifier als Security Token Service in Ihrem SAP-System registrieren. Dies geschieht durch Hochladen einer von Simplifier generierten Metadatendatei, die alle relevanten Informationen enthält.
Schritt 5-1: Zertifikat in Simplifier hochladen
Laden Sie die in Schritt 4 generierten Zertifikatsdateien in Simplifier hoch:
Schritt 5-2 Metadaten generieren
Um die Metadaten zu generieren, erstellen Sie eine
Nach dem Speichern der Anmeldemethode können Sie die Metadatendatei herunterladen:
Schritt 5-3 Metadaten in SAP hochladen
1. Starten Sie die Transaktion SAML2 und öffnen Sie den Browser-Tab TRUSTED PROVIDERS:
2. Wählen Sie SECURITY TOKEN SERVICES, klicken Sie auf ADD und wählen Sie UPLOAD METADATA FILE:
2. Simplifier-Metadatendatei hochladen
3. Überprüfen Sie die automatisch ausgefüllten Einträge für Schritt 2-6 und klicken Sie auf FINISH.
5. EDIT den neu erstellten Trusted Provider, um die unterstützte SAML-Version zu konfigurieren:
6. Gehen Sie zum Browser-Tab IDENTITY FEDERATION und fügen Sie unterstützte NAME ID FORMATS hinzu:
6.0 Fügen Sie den Typ unspecified: hinzu
6.1 Wenn Ihr Benutzername innerhalb Ihrer zentralen Identitätsverwaltung derselbe ist wie der SAP-Benutzername, können Sie LOGIN ID wählen:
6.2 Wenn Ihr Benutzername nicht derselbe ist wie Ihr SAP-Benutzername, müssen Sie den Benutzerzuordnungsmodus ASSIGNMENT IN USREXTID TABLE, TYPE SA wählen:
7. Klicken Sie auf SAVE und aktivieren Sie den neu erstellten Security Token Service (STS) mit der Schaltfläche ENABLE.
Schritt 5-4 Benutzerzuordnung in SAP (optional)
Wenn Ihre eindeutige Kennung Ihres zentralen Identity Providers nicht mit dem SAP-Benutzernamen übereinstimmt, müssen Sie die Zuordnung über <SAML-Benutzer> zu <SAP-Benutzer> durch Pflegen der Tabelle VUSREXTID pflegen.
Wenn der SAML-Eigentümer mit dem ABAP-Benutzernamen identisch ist, kann die Zuordnung direkt mit dem Report RSUSREXT vorgenommen werden.
Starten Sie andernfalls die Transaktion SM30 und zeigen Sie die Tabelle VUSREXTID an:
Wählen Sie SA als externen ID-Typ aus:
Einträge hinzufügen:
Schritt 6: WSS-Login für SOAP Konnektoren verwenden
Sie können nun den WSS-Login-Mechanismus aus Schritt 5 als Anmeldemethode für Ihre SOAP Konnektoren auswählen:
Für die App-Anmeldung führen Sie den Login App Wizard für die SAML-Authentifizierung aus. Die resultierende Prozess-Story sollte wie folgt aussehen:
