Voraussetzungen:

Der Simplifier-SSO-Mechanismus verwendet die SAP-Standardberechtigungen und bereits zugewiesene SAP-Rollen.

• Lesezugriff auf Daten, d.h. es muss sichergestellt sein, dass der Anrufer über die notwendigen Berechtigungen verfügt, und
• Änderungen müssen revisionsfähig sein, d.h. es muss nachvollziehbar sein, wer Änderungen an Daten veranlasst hat.

Funktionierender Identitätsanbieter

Dieses SAP-Single-Sign-On-Szenario funktioniert mit allen von SAML 2.0 unterstützten Identitätsanbietern, z. B.:

• OnPremise Azure Active Directory über ADFS
• Azure Active Directory
• Google über SAML
• und viele mehr

Single Sign-On mit SAML-Absender bürgt zwischen Simplifier und SAP Application Server ABAP 7.x

Die folgende Abbildung veranschaulicht den Single Sign-On-Mechanismus:

Wie funktioniert das?

Der Benutzer fordert die Anmeldung mit einem Client (Browser oder Simplifier Mobile Client App) bei einer Simplifier-Anwendung an, wobei er den vorkonfigurierten Identitätsanbieter über SAML 2.0 verwendet.
Der Identitätsanbieter zeigt seine Anmeldeseite an, und der Benutzer kann authentifiziert werden.
Nach der Autorisierung wird der Benutzer zurück zur Simplifier-Anwendung weitergeleitet und der Simplifier speichert den bereitgestellten Sicherheitsschlüssel in einem gesicherten Schlüsseltresorspeicher (SAML Assertion).
Wenn eine SOAP-Anfrage von der Simplifier-Anwendung ausgeführt wird, fügt der Simplifier selbst den Sicherheitsschlüssel hinzu, signiert die gesamte Anfrage – einschließlich der Daten – mit einem Zertifikat und sendet sie an das SAP-Backend.
Simplifier agiert daher in der Rolle als Security Token Service.
SAP Enterprise Webservices, die vom Simplifier SOAP Connector adressiert werden, empfangen Messages über das Internet Communication Framework (ICF), das die HTTP-Requests empfängt und einen AS ABAP-Workprozess zur Verarbeitung zuordnet.
Alle Authentifizierungsmethoden, die von der ICF unterstützt werden, basieren auf Übertragungen auf SSL-Protokollebene oder als HTTP-Header.
Bei einer nachrichtenbasierten Anmeldung, z.B. über Benutzernamen-Token, SAML-Token oder X.509-Zertifikat, sind die Daten nicht Teil eines HTTP-Headers, sondern befinden sich in einem SOAP-Header, auf den der ICF keinen Zugriff hat.
Daher ist kein direkter Login möglich, sondern der ICF führt zunächst einen Login mit einem technischen Benutzer (z.B. DELAY_LOGON) durch.
Nach erfolgreicher Sicherheitsverarbeitung wird ein Benutzerwechsel entsprechend der konfigurierten Authentifizierung durchgeführt.

Schritt 1 – Prüfung der SAP Cryptographic Library

Die für WS-Security erforderlichen RSA-Signaturen und Verschlüsselungsfunktionen stehen in einer separaten Bibliothek, der SAP Cryptographic Library, zur Verfügung, die auf dem SAP Service Marketplace bezogen werden kann.
Informationen darüber, wie Sie diese Bibliothek erhalten, finden Sie im SAP-Hinweis 397175.
Die Bibliothek muss in der Version “SSFLIB Version 1.555.24 ; SECUDE(tm) SAPCRYPTOLIB” oder höher.
Gehen Sie in die Transaktion STRUST und wählen Sie das Menü Umfeld -> SSF-Version anzeigen

Schritt 2 – Überprüfen Sie die Sicherheitseinrichtung des Webdienstes

Jede nachrichtenbasierte Authentifizierung wird technisch durch Ändern des Benutzer DELAY_L_<SID> (Versionen 7.0X) oder DELAY_LOGON (Versionen 7.10 und höher) an den Benutzer, der durch den Sicherheitsheader authentifiziert wird.
Der Benutzer DELAY_L_<SID>/DELAY_LOGON wird von Report wss_setup erstellt, und der Benutzername und das Kennwort werden im sicheren Speicher des Systems gespeichert.
Um den Benutzer anzulegen, müssen die folgenden Voraussetzungen erfüllt sein:

• Das System muss die Anmeldung mit Benutzername und Kennwort zulassen.
  Wenn die kennwortbasierte Anmeldung im System generell deaktiviert ist, muss der Benutzer DELAY_LOGON in eine Gruppe aufgenommen werden, die die kennwortbasierte Anmeldung zulässt.
• Bei Systemen, die Teil einer zentralen Benutzerverwaltung (ZBV) sind, ist sicherzustellen, dass die Generierung von Benutzern in ZBV-Tochtersystemen zulässig ist.

Um den DELAY_LOGON Benutzer 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 Bericht auszuführen, drücken Sie F8.

Schritt 3 – Einrichten des SAP-Webservice

Die Konfiguration der SAP-Webservices erfolgt über die Transaktion SOAMANAGER.
Führen Sie die folgenden Schritte aus, um eine Konfiguration für die SAML-Authentifizierung für jeden einzelnen Webserver zu erstellen:

Schritt 3-1 – Öffnen Sie den SOA Manager

Führen Sie die Transaktion SOAMANAGER aus, woraufhin das System einen neuen Browser-Tab startet.
Wählen Sie nun auf der Registerkarte Dienstverwaltung die Option Webdienstkonfiguration aus.

Schritt 3-2 Betroffenen Webservice auswählen

Suchen Sie nach dem Webdienst und wählen Sie diesen aus, indem Sie auf den Link klicken, siehe Schritt 2 unten:

Schritt 3-3: Erstellen eines Dienstendpunkts

Wählen Sie Create Service (Dienst erstellen) aus, um eine neue Konfiguration zu erstellen.

Schritt 3-4: Konfigurieren des Bindungsnamens

Konfigurieren eines technischen Namens und eines Bindungsnamens (können identisch sein) für die Webservice-Definition

Schritt 3-5: Konfigurieren der Anbietersicherheit

Um die Message für die Transportsicherheit zu verschlüsseln, wählen Sie HTTPS als Transportgarantietyp aus.
Legen Sie die Sicherheit auf Nachrichtenebene auf “Keine” fest.
Wählen Sie für Single Sign-On über SAML-Absenderbürgschaften Single Sign-On mit SAML als Authentifizierungsmethode aus.

Schritt 3-7: Konfigurieren des SOAP-Protokolls

In diesem Schritt können Sie die Standardeinstellungen wie unten beschrieben beibehalten

Schritt 3-8: Konfigurieren der Betriebseinstellungen

In diesem Schritt können Sie die Standardeinstellungen wie unten beschrieben beibehalten und die Einrichtung des Webservice abschließen

Schritt 4: Installieren des Zertifikats für den Sicherheitstokendienst

Für den Signiervorgang des SOAP-Requests benötigen der Simplifier und SAP eine vertrauenswürdige Beziehung.
Daher benötigen Sie ein gültiges Zertifikat mit einer Signaturfunktion, die beiden Systemen (Simplifier und SAP) bekannt ist.

Schritt 4-1 Selbstsignaturzertifikat generieren

In diesem Artikel verwenden wir ein Hilfstool namens mkcert , um den Prozess zu vereinfachen.
Sie können mkcert hier herunterladen. Generieren Sie nach der Installation des mkcert-Tools ein neues Zertifikat:

mkcert simplifier@myenterprise.com

Schritt 4-2: Überprüfen des generierten Zertifikats

Bevor Sie das Zertifikat in Simplifier und SAP hochladen, sollten Sie überprü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 “Digitale Signatur” anzeigen.

Schritt 4-3: Hochladen des generierten Zertifikats in SAP

Um Ihr Zertifikat hochzuladen, müssen Sie die Erlaubnis für die Transaktion STRUST haben.
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 Certificate Public Key File (*.pem) von Ihrem lokalen Client

Nachdem Sie die Zertifikatinformationen ü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: Herstellen einer vertrauenswürdigen Beziehung

Die Authentifizierung einer SAML-Assertion erfordert eine vertrauenswürdige Beziehung zwischen dem Simplifier und SAP.
Daher müssen Sie den Simplifier als Security Token Service in Ihrem SAP-System registrieren.
Dies geschieht durch das 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

Zum Erzeugen der
Metadaten erstellen eine
login-Methode vom Typ
WSS:

Nachdem Sie die Anmeldemethode gespeichert haben, können Sie die Metadatendatei herunterladen:

Schritt 5-3: Hochladen von Metadaten in SAP

1.Starten Sie die Transaktion SAML2 und öffnen Sie den Browser-Tab TRUSTED PROVIDERS:

2. Wählen Sie SICHERHEITSTOKENDIENSTE aus, klicken Sie auf HINZUFÜGEN und wählen Sie METADATENDATEI HOCHLADEN aus:

2. Laden Sie die Simplifier-Metadatendatei hoch

3. Überprüfen Sie die automatisch ausgefüllten Einträge für Schritt 2-6 und klicken Sie auf FERTIGSTELLEN.

5. BEARBEITEN Sie den neu erstellten vertrauenswürdigen Anbieter, um die unterstützte SAML-Version zu konfigurieren:

6. Gehen Sie zur Registerkarte IDENTITY FEDERATION browser und fügen Sie unterstützte NAME ID-FORMATE hinzu:

6.0 Typ nicht angegeben hinzufügen:

6.1 Wenn Ihr Benutzername in Ihrem zentralen Identitätsmanagement mit dem SAP-Benutzernamen übereinstimmt, können Sie LOGIN ID wählen:

6.2 Wenn Ihr Benutzername nicht mit Ihrem SAP-Benutzernamen übereinstimmt, müssen Sie den Benutzerzuordnungsmodus wählen. ZUWEISUNG IN DER USREXTID-TABELLE, GEBEN SIE SA EIN:

7. Klicken Sie auf SPEICHERN und aktivieren Sie den neu erstellten Security Token Service (STS) über die Schaltfläche ENABLE.

Schritt 5-4 Benutzerzuordnung in SAP (optional)

Wenn Ihr Unique Identifier Ihres Central Identity Providers nicht mit dem sap username identisch ist, müssen Sie das Mapping über <SAML-Benutzer> An <SAP-Anwender> durch Pflege der Tabelle VUSREXTID.
Wenn der SAML-Owner identisch mit dem ABAP-Benutzernamen ist, kann die Zuordnung direkt mit dem Report RSUSREXT erfolgen.
Andernfalls starten Sie die Transaktion SM30 und zeigen die Tabelle VUSREXTID an:

Wählen Sie SA als externen ID-Type:

Einträge hinzufügen:

Schritt 6: Verwenden der WSS-Anmeldung für SOAP-Konnektoren

Sie können nun den WSS-Anmeldemechanismus aus Schritt 5 als Anmeldemethode für Ihre SOAP-Konnektoren auswählen:

Führen Sie für die App-Anmeldung den Anmelde-App-Assistenten für die SAML-Authentifizierung aus.
Die resultierende Prozessstory sollte wie folgt aussehen: