Teilen über

Szenario: Verwenden von Microsoft Entra ID zum Schützen des Zugriffs auf SAP-Plattformen und -Anwendungen

  • Artikel

Dieses Dokument enthält Ratschläge zum technischen Entwurf und zur Konfiguration von SAP-Plattformen und -Anwendungen, wenn Microsoft Entra ID als primärer Authentifizierungsdienst für SAP Cloud Identity Services verwendet wird. SAP Cloud Identity Services umfasst Identity Authentication, Identity Provisioning, Identity Directory und Authorization Management. Weitere Informationen zur Ersteinrichtung für die Authentifizierung finden Sie unter Tutorial: Integration des einmaligen Anmeldens (SSO) von Microsoft Entra in SAP Cloud Identity Services. Weitere Informationen zur Bereitstellung und zu anderen Szenarien finden Sie unter Planen der Bereitstellung von Microsoft Entra für die Benutzerbereitstellung mit Quell- und Ziel-Apps von SAP und Verwalten des Zugriffs auf Ihre SAP-Anwendungen.

Terminologie in dieser Anleitung

Abkürzung BESCHREIBUNG
BTP SAP Business Technology Platform ist eine Innovationsplattform, die für SAP-Anwendungen in der Cloud optimiert ist. Die meisten der hier beschriebenen SAP-Technologien sind Bestandteil von BTP. Die Produkte, die formell als SAP Cloud Platform bezeichnet werden, sind Bestandteil von SAP BTP.
IAS SAP Cloud Identity Services – Identity Authentication, eine Komponente von SAP Cloud Identity Services, ist ein Clouddienst für Authentifizierung, einmaliges Anmelden und Benutzerverwaltung in cloudbasierten und lokalen SAP-Anwendungen. IAS unterstützt Benutzer dabei, sich bei ihren eigenen SAP BTP-Dienstinstanzen als Proxy zu authentifizieren, der in einmaliges Anmelden von Microsoft Entra integriert wird.
IPS SAP Cloud Identity Services – Identity Provisioning, eine Komponente von SAP Cloud Identity Services, ist ein Clouddienst, der Ihnen hilft, Identitäten und deren Autorisierung in cloudbasierten und lokalen SAP-Anwendungen bereitzustellen.
XSUAA Extended Services for Cloud Foundry User Account and Authentication. Cloud Foundry, eine PaaS-Lösung (Platform-as-a-Service), die auf verschiedenen Infrastrukturen bereitgestellt werden kann, ist die Umgebung, auf der SAP Business Technology Platform aufbaut. XSUAA ist ein mehrinstanzenfähiger OAuth-Autorisierungsserver, der die zentrale Infrastrukturkomponente der Cloud Foundry-Umgebung bildet. XSUAA ermöglicht die Authentifizierung und Autorisierung von Geschäftsbenutzern in SAP BTP.
Fiori Die webbasierte Benutzeroberfläche von SAP (im Gegensatz zur desktopbasierten Benutzeroberfläche).

Überblick

Es gibt viele Dienste und Komponenten im SAP- und Microsoft-Technologiestapel, die in Szenarien für die Authentifizierung und Autorisierung von Benutzern eine Rolle spielen. Die wichtigsten Dienste sind im folgenden Diagramm aufgeführt.

Übersicht über die SAP-Landschaft

Da es viele Variationen möglicher Szenarien gibt, die konfiguriert werden müssen, konzentrieren wir uns auf ein Szenario, in dem die Microsoft Entra-Identität bevorzugt verwendet wird. Wir gehen von folgenden Annahmen aus:

  • Sie möchten alle Ihre Identitäten zentral und nur über Microsoft Entra ID steuern.
  • Sie möchten den Wartungsaufwand so weit wie möglich reduzieren sowie Authentifizierung und App-Zugriff Microsoft- und SAP-übergreifend automatisieren.
  • Die allgemeine Anleitung für Microsoft Entra ID mit IAS gilt für Apps, die in BTP- und SAP SaaS-Apps bereitgestellt werden, die in IAS konfiguriert wurden. Darüber hinaus werden ggf. spezielle Empfehlungen für BTP (z. B. die Verwendung von Rollenzuordnungen über Microsoft Entra ID-Gruppen) und SAP SaaS-Apps (z. B. die Verwendung des Identitätsbereitstellungsdiensts für die rollenbasierte Autorisierung) bereitgestellt.
  • Außerdem wird davon ausgegangen, dass Benutzer bereits in Microsoft Entra ID und für alle SAP-Systeme bereitgestellt wurden, die voraussetzen, dass Benutzer bereitgestellt werden, damit sie funktionieren. Dies gilt unabhängig davon, wie die Bereitstellung durchgeführt wurde: manuell, von einer lokalen Active Directory-Instanz über Microsoft Entra Connect oder über Personalverwaltungssysteme wie SAP SuccessFactors. In diesem Dokument wird SuccessFactors daher wie jede andere Anwendung angesehen, bei der sich (vorhandene) Benutzer anmelden. Die eigentliche Bereitstellung von Benutzern aus SuccessFactors inMicrosoft Entra ID wird nicht behandelt. Weitere Informationen darüber, wie Sie Microsoft Entra ID-Benutzerkonten für die Verwendung mit SAP-Workloads konfigurieren, finden Sie unter Planen der Bereitstellung von Microsoft Entra für die Benutzerbereitstellung mit Quell- und Ziel-Apps von SAP und Verwalten des Zugriffs auf Ihre SAP-Anwendungen.

Basierend auf diesen Annahmen konzentrieren wir uns hauptsächlich auf die Produkte und Dienste, die im folgenden Diagramm dargestellt sind. Dabei handelt es sich um die verschiedenen Komponenten, die für die Authentifizierung und Autorisierung in einer cloudbasierten Umgebung besonders relevant sind.

SAP-Dienste im Bereich

Wenn Sie SAP Identity Management (IDM) verwendet haben, können Sie Identitätsverwaltungsszenarien von SAP IDM zu Microsoft Entra migrieren. Weitere Informationen finden Sie unter Migrieren von Identitätsverwaltungsszenarien von SAP IDM zu Microsoft Entra.

Hinweis

Die meisten der hier aufgeführten Hinweise gelten auch für Azure Active Directory B2C, aber es gibt einige wichtige Unterschiede. Weitere Informationen finden Sie unter Verwenden von Azure AD B2C als Identitätsanbieter.

Warnung

Beachten Sie die Grenzwerte für SAP SAML-Assertionen sowie die Auswirkungen der Länge der SAP Cloud Foundry-Rollensammlungsnamen und der Anzahl der Sammlungen, die von Gruppen in SAP Cloud-Identitätsdienst als Proxy verwendet werden. Weitere Informationen finden Sie im SAP-Hinweis 2732890 in SAP for Me. Überschreitungen führen zu Autorisierungsproblemen.

Empfehlungen

Zusammenfassung

1\. Verwendung der Verbundauthentifizierung in SAP Business Technology Platform- und SAP SaaS-Anwendungen über SAP Identity Authentication Service

Kontext

Ihre Anwendungen in BTP können Identitätsanbieter über Vertrauensstellungskonfigurationen verwenden, um Benutzer über das SAML 2.0-Protokoll zwischen BTP/XSUAA und dem Identitätsanbieter zu authentifizieren. Beachten Sie, dass nur SAML 2.0 unterstützt wird, obwohl zwischen der Anwendung selbst und BTP/XSUAA das OpenID Connect-Protokoll verwendet wird (in diesem Kontext nicht relevant).

In BTP können Sie eine Vertrauensstellungskonfiguration für SAP Cloud Identity Services – Identity Authentication (Standardeinstellung) einrichten. Wenn als autoritatives Benutzerverzeichnis jedoch Microsoft Entra ID verwendet wird, können Sie einen Verbund einrichten, damit sich Benutzer mit ihren vorhandenen Microsoft Entra-Konten anmelden können.

Zusätzlich zum Verbund können Sie optional auch die Benutzerbereitstellung so einrichten, dass Microsoft Entra-Benutzer vorab in BTP bereitgestellt werden. Es gibt dafür jedoch keine native Unterstützung (nur für Microsoft Entra ID -> SAP Identity Authentication Service). Eine integrierte Lösung mit nativer Unterstützung wäre der BTP Identity Provisioning Service. Die Vorabbereitstellung von Benutzerkonten kann für Autorisierungszwecke nützlich sein (z. B. zum Hinzufügen von Benutzern zu Rollen). Abhängig von den jeweiligen Anforderungen können Sie dies jedoch auch mit Microsoft Entra-Gruppen erreichen (siehe unten), sodass Sie u. U. überhaupt keine Benutzerbereitstellung benötigen.

Beim Einrichten der Verbundbeziehung gibt es mehrere Optionen:

  • Sie können einen Verbund mit Microsoft Entra ID direkt über BTP/XSUAA erstellen.
  • Sie können einen Verbund mit IAS erstellen, der wiederum als Verbund mit Microsoft Entra ID als Unternehmensidentitätsanbieter eingerichtet ist (auch als „SAML-Proxying“ bezeichnet).

Für SAP SaaS-Anwendungen wird IAS bereitgestellt und vorkonfiguriert, um das Onboarding von Endbenutzern zu vereinfachen. (Beispiele hierfür sind SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud und andere.) Dieses Szenario ist weniger komplex, weil IAS direkt mit der Ziel-App und nicht über einen Proxy mit XSUAA verbunden ist. In jedem Fall gelten für diese Einrichtung die gleichen Regeln wie für Microsoft Entra ID mit IAS im Allgemeinen.

Unsere Empfehlung

Wenn Sie Microsoft Entra ID als autoritatives Benutzerverzeichnis verwenden, wird empfohlen, in BTP eine Vertrauensstellungskonfiguration zu IAS einzurichten. IAS wiederum wird als Verbund mit Microsoft Entra ID als Unternehmensidentitätsanbieter eingerichtet.

SAP-Vertrauensstellungskonfiguration

Für die Vertrauensstellungskonfiguration in BTP wird empfohlen, die Erstellung von Schattenbenutzern bei der Anmeldung zu aktivieren. Auf diese Weise erhalten Benutzer, die noch nicht in BTP erstellt wurden, automatisch ein Konto, wenn sie sich zum ersten Mal über IAS/Microsoft Entra ID anmelden. Wenn diese Einstellung deaktiviert wird, dürfen sich nur vorab bereitgestellte Benutzer anmelden.

Gründe für diese Empfehlung

Bei Verwendung eines Verbunds können Sie die Vertrauensstellungskonfiguration auf der Ebene von BTP-Unterkonten definieren. In diesem Fall müssen Sie die Konfiguration für jedes andere verwendete Unterkonto wiederholen. Durch die Verwendung von IAS als zwischengelagerte Vertrauensstellungskonfiguration profitieren Sie von der zentralisierten unterkontoübergreifenden Konfiguration. Außerdem können Sie IAS-Features wie risikobasierte Authentifizierung und zentrale Anreicherung von Assertionsattributen verwenden. Um die Benutzerfreundlichkeit zu gewährleisten, sollten diese erweiterten Sicherheitsfeatures nur an einer einzigen Stelle erzwungen werden. Dies kann entweder IAS sein oder bei Beibehaltung von Microsoft Entra ID als einzelner autoritativer Benutzerspeicher (wie in diesem Whitepaper vorausgesetzt) zentral über die bedingte Zugriffsverwaltung von Microsoft Entra bewerkstelligt werden.

Beachten Sie, dass bei Verwendung von IAS jedes Unterkonto als „Anwendung“ gilt, obwohl im betreffenden Unterkonto eine oder mehrere Anwendungen bereitgestellt werden können. In IAS kann jede derartige Anwendung für den Verbund mit demselben Unternehmensidentitätsanbieter eingerichtet werden (in diesem Fall Microsoft Entra ID).

Zusammenfassung der Implementierung

In Microsoft Entra ID:

In Microsoft Entra ID und IAS:

  • Befolgen Sie die Anweisungen in der entsprechenden Dokumentation, um Microsoft Entra ID im Verbundmodus (Proxy) mit IAS zu verbinden (SAP-Dokumentation, Microsoft-Dokumentation). Achten Sie auf die Einstellung NameID in Ihrer SSO-Konfiguration in Microsoft Entra ID, da UPNs nicht unbedingt E-Mail-Adressen sind.
  • Konfigurieren Sie die gebündelte Anwendung für die Verwendung von Microsoft Entra ID. Rufen Sie dazu die Seite Bedingte Authentifizierung auf, und legen Sie den Standardauthentifizierungsidentitätsanbieter auf den Unternehmensidentitätsanbieter fest, der Ihr Microsoft Entra-Verzeichnis darstellt.

In BTP:

  • Richten Sie eine Vertrauensstellungskonfiguration zu IAS ein (SAP-Dokumentation), und vergewissern Sie sich, dass „Available for User Logon“ (Für Benutzeranmeldung verfügbar) und „Create Shadow Users During Logon“ (Schattenbenutzer bei der Anmeldung erstellen) aktiviert sind.
  • Deaktivieren Sie ggf. „Für Benutzeranmeldung verfügbar“ (Available for User Logon) in der Standardkonfiguration für die SAP ID Service-Vertrauensstellung, sodass sich Benutzer immer über Microsoft Entra ID authentifizieren und kein Bildschirm angezeigt wird, in dem sie den Identitätsanbieter auswählen können.

2. Verwendung von Microsoft Entra ID für die Authentifizierung und von IAS/BTP für die Autorisierung

Kontext

Wenn BTP und IAS für die Benutzerauthentifizierung über einen Verbund mit Microsoft Entra ID konfiguriert wurden, gibt es mehrere Konfigurationsoptionen für die Autorisierung:

  • In Microsoft Entra-ID können Sie der Unternehmensanwendung Microsoft Entra Benutzer und -Gruppen zuweisen, die Ihre SAP IAS-Instanz in Microsoft Entra ID abbilden.
  • In IAS können Sie die risikobasierte Authentifizierung verwenden, um Anmeldungen zuzulassen oder zu sperren und so den Zugriff auf die Anwendung in BTP zu verhindern.
  • In BTP können Sie über Rollensammlungen definieren, welche Benutzer und Gruppen auf die Anwendung zugreifen und bestimmte Rollen erhalten können.

Unsere Empfehlung

Es wird empfohlen, die Autorisierung nicht direkt in Microsoft Entra selbst durchzuführen und in Microsoft Entra ID für die Unternehmensanwendung die Option „Benutzerzuweisung erforderlich“ explizit zu deaktivieren. Beachten Sie, dass diese Einstellung für SAML-Anwendungen standardmäßig aktiviert ist, sodass Sie diese Einstellung explizit deaktivieren müssen.

Gründe für diese Empfehlung

Bei Erstellung des Anwendungsverbunds über IAS wird der Benutzer aus der Sicht von Microsoft Entra ID im Rahmen des Anmeldeflows eigentlich bei IAS authentifiziert. Dies bedeutet, dass Microsoft Entra ID keine Informationen darüber hat, bei welcher BTP-Anwendung sich der Benutzer letztendlich anmelden möchte. Dies bedeutet auch, dass die Autorisierung in Microsoft Entra ID nur für eine sehr grobe Autorisierung verwendet werden kann, z. B. dass sich der Benutzer bei jeder beliebigen oder bei keiner Anwendung in BTP anmelden kann. Dies betont auch die SAP-Strategie, Apps und Authentifizierungsmechanismen auf der Ebene von BTP-Unterkonten zu isolieren.

Obwohl dies ein berechtigter Grund für die Verwendung der Option „Benutzerzuweisung erforderlich“ sein kann, bedeutet dies, dass es jetzt möglicherweise zwei verschiedene Stellen gibt, an denen Autorisierungsinformationen verwaltet werden müssen: sowohl in Microsoft Entra ID für die Unternehmensanwendung (wo sie für alle BTP-Anwendungen gelten) als auch in jedem BTP-Unterkonto. Dies kann zu Verwirrung und Fehlkonfigurationen führen, wenn Autorisierungseinstellungen an einer Stelle, aber nicht an der anderen Stelle aktualisiert werden. Wenn beispielsweise ein Benutzer in BTP zugelassen, aber in Microsoft Entra ID nicht der Anwendung zugewiesen wurde, tritt bei der Authentifizierung ein Fehler auf.

Zusammenfassung der Implementierung

Deaktivieren Sie für die Microsoft Entra-Unternehmensanwendung, die die Verbundbeziehung mit IAS darstellt, die Option „Benutzerzuweisung erforderlich“. Dies bedeutet auch, dass Sie die Zuweisung von Benutzern problemlos überspringen können.

3. Verwendung von Microsoft Entra-Gruppen für die Autorisierung über Rollensammlungen in IAS/BTP

Kontext

Wenn Sie die Autorisierung für Ihre BTP-Anwendungen konfigurieren möchten, gibt es mehrere Optionen:

  • Sie können eine differenzierte Zugriffssteuerung in der Anwendung selbst abhängig vom jeweils angemeldeten Benutzer konfigurieren.
  • Sie können den Zugriff über Rollen und Rollensammlungen in BTP basierend auf Benutzerzuweisungen oder Gruppenzuweisungen angeben.

Die endgültige Implementierung kann eine Kombination beider Strategien verwenden. Für die Zuweisung über Rollensammlungen kann dies benutzerspezifisch erfolgen, oder es können Gruppen des konfigurierten Identitätsanbieters verwendet werden.

Unsere Empfehlung

Wenn Sie Microsoft Entra ID als autoritative Quelle für eine differenzierte Autorisierung verwenden möchten, empfiehlt es sich, Microsoft Entra-Gruppen zu verwenden und diese Rollensammlungen in BTP zuzuweisen. Um Benutzer Zugriff auf bestimmte Anwendungen zu gewähren, müssen die Benutzer lediglich zu den relevanten Microsoft Entra-Gruppen hinzugefügt werden, ohne dass eine weitere Konfiguration in IAS/BTP erforderlich ist.

Bei dieser Konfiguration wird empfohlen, die Gruppen-ID (Objekt-ID) der Microsoft Entra-Gruppe und nicht den Anzeigenamen („sAMAccountName“) als eindeutigen Bezeichner für die Gruppe zu verwenden. Dies bedeutet, dass Sie die Gruppen-ID als „Group“-Assertion im SAML-Token verwenden müssen, das von Microsoft Entra ID ausgestellt wird. Darüber hinaus wird die Gruppen-ID für die Zuweisung zur Rollensammlung in BTP verwendet.

Verwendung von Rollensammlungen in SAP

Gründe für diese Empfehlung

Wenn Sie Benutzer direkt Rollensammlungen in BTP zuweisen, werden Autorisierungsentscheidungen nicht in Microsoft Entra ID zentralisiert. Dies bedeutet auch, dass der Benutzer bereits in IAS vorhanden sein muss, damit er einer Rollensammlung in BTP zugewiesen werden kann. Da wir einen Verbund anstelle der Benutzerbereitstellung empfehlen, bedeutet dies, dass das Schattenkonto des Benutzers zum gewünschten Zeitpunkt der Benutzerzuweisung u. U. noch nicht in IAS vorhanden ist. Wenn Sie Microsoft Entra-Gruppen verwenden und diese Gruppen Rollensammlungen zuweisen, entfallen diese Probleme.

Das Zuweisen von Gruppen zu Rollensammlungen scheint der vorherigen Empfehlung zu widersprechen, Microsoft Entra ID nicht für die Autorisierung zu verwenden. Aber sogar in diesem Fall fällt die Autorisierungsentscheidung weiterhin in BTP. Die Entscheidung basiert jetzt allerdings nur auf einer Gruppenmitgliedschaft, die in Microsoft Entra ID verwaltet wird.

Es wird empfohlen, die Gruppen-ID der Microsoft Entra-Gruppe und nicht den Namen der Gruppe zu verwenden, da die Gruppen-ID global eindeutig und unveränderlich ist. Darüber hinaus kann sie zu einem späteren Zeitpunkt nie für eine andere Gruppe wiederverwendet werden. Demgegenüber kann die Verwendung des Gruppennamens zu Problemen führen, wenn der Name geändert wird. Außerdem besteht ein Sicherheitsrisiko darin, dass eine Gruppe gelöscht und eine andere Gruppe mit dem gleichen Namen erstellt wird, die aber Benutzer enthält, die keinen Zugriff auf die Anwendung haben sollten.

Zusammenfassung der Implementierung

In Microsoft Entra ID:

  • Erstellen Sie Gruppen, zu denen die Benutzer hinzugefügt werden können, die Zugriff auf Anwendungen in BTP benötigen. (Erstellen Sie z. B. eine Microsoft Entra-Gruppe für jede Rollensammlung in BTP.)
  • Konfigurieren Sie für die Microsoft Entra-Unternehmensanwendung, die die Verbundbeziehung mit IAS darstellt, die SAML-Benutzerattribute & -Ansprüche, um einen Gruppenanspruch für Sicherheitsgruppen hinzuzufügen:

    • Legen Sie das Quellattribut auf „Gruppen-ID“ und den Namen auf Groups fest (exakt wie hier mit dem Großbuchstaben „G“ geschrieben).

    • Außerdem wird dringend empfohlen, die in den Ansprüchen zurückgegebenen Gruppen auf die Gruppen zu beschränken, die explizit zugewiesen wurden, um die Anspruchsnutzdaten klein zu halten und zu vermeiden, dass Microsoft Entra ID die Anzahl von Gruppenansprüchen in SAML-Assertionen auf 150 beschränkt:

      • Wählen Sie unter „Welche dem Benutzer zugeordneten Gruppen sollen im Anspruch zurückgegeben werden?“ die Option „Der Anwendung zugewiesene Gruppen“ aus. Weisen Sie sie dann für die Gruppen, die Sie als Ansprüche einbeziehen möchten, der Unternehmensanwendung zu, indem Sie im Abschnitt „Benutzer und Gruppen“ die Option „Benutzer/Gruppe hinzufügen“ auswählen.

      Konfiguration der Ansprüche von Microsoft Entra-Gruppen

In IAS:

  • Achten Sie in der Konfiguration des Unternehmensidentitätsanbieters unter den Optionen für den Identitätsverbund darauf, dass „Use Identity Authentication user store“ (Identity Authentication-Benutzerspeicher verwenden) deaktiviert ist. Andernfalls gehen die Gruppeninformationen von Microsoft Entra ID im SAML-Token für BTP verloren, sodass die Autorisierung fehlschlägt.

Hinweis

Wenn Sie den Identity Authentication-Benutzerspeicher verwenden müssen (z. B. um Ansprüche einzubeziehen, die nicht aus Microsoft Entra ID bezogen werden können, aber im IAS-Benutzerspeicher verfügbar sind), können Sie diese Einstellung aktiviert lassen. In diesem Fall müssen Sie jedoch die an die Anwendung gesendeten Standardattribute so konfigurieren, dass sie die entsprechenden Ansprüche aus Microsoft Entra ID enthalten (z. B. mit dem ${corporateIdP.Groups}-Format).

In BTP:

  • Führen Sie für die Rollensammlungen, die von den Anwendungen im betreffenden Unterkonto verwendet werden, eine Zuordnung der Rollensammlungen zu Benutzergruppen durch, indem Sie eine Konfiguration für den IAS-Identitätsanbieter hinzufügen und den Namen auf die Gruppen-ID (Objekt-ID) der Microsoft Entra-Gruppe festlegen.

Hinweis

Falls Sie einen anderen Anspruch in Microsoft Entra ID haben, der die in BTP zu verwendenden Autorisierungsinformationen enthält, müssen Sie den Namen des Groups-Anspruchs nicht verwenden. Dieser wird von BTP verwendet, wenn Sie die Rollensammlungen wie oben beschrieben Benutzergruppen zuordnen. Sie können jedoch auch die Rollensammlungen Benutzerattributen zuordnen, was Ihnen ein wenig mehr Flexibilität bietet.

4\. Verwendung lediglich eines einzelnen BTP-Unterkontos für Anwendungen mit ähnlichen Identitätsanforderungen

Kontext

In BTP kann jedes Unterkonto mehrere Anwendungen enthalten. Aus Sicht von IAS handelt es sich bei einer „gebündelten Anwendung“ jedoch um ein vollständiges BTP-Unterkonto, und nicht um die darin differenzierten Anwendungen. Dies bedeutet, dass alle Vertrauenseinstellungen, Authentifizierung und Zugriffskonfiguration sowie Branding- und Layoutoptionen in IAS für alle Anwendungen innerhalb dieses Unterkontos gelten. Ebenso gelten alle Vertrauensstellungskonfigurationen und Rollensammlungen in BTP auch für alle Anwendungen im betreffenden Unterkonto.

Unsere Empfehlung

Es wird empfohlen, mehrere Anwendungen nur dann in einem einzelnen BTP-Unterkonto zu gruppieren, wenn sie ähnliche Anforderungen auf Identitätsebene haben (Benutzer, Gruppen, Identitätsanbieter, Rollen, Vertrauensstellungskonfiguration, Branding usw.).

Gründe für diese Empfehlung

Wenn Sie mehrere Anwendungen mit sehr unterschiedlichen Identitätsanforderungen in einem einzelnen Unterkonto in BTP gruppieren, kann eine Konfiguration entstehen, die unsicher ist oder leichter falsch konfiguriert werden kann. Wenn beispielsweise für eine freigegebene Ressource, z. B. einen Identitätsanbieter, für eine einzelne Anwendung in BTP eine Konfigurationsänderung vorgenommen wird, wirkt sich dies auf alle Anwendungen aus, die auf dieser freigegebenen Ressource basieren.

Zusammenfassung der Implementierung

Überlegen Sie sorgfältig, wie Sie mehrere Anwendungen über Unterkonten in BTP gruppieren möchten. Weitere Informationen finden Sie in der Dokumentation zum SAP-Kontenmodell.

5\. Verwendung des IAS-Mandanten der Produktionsumgebung für die Authentifizierung und Autorisierung aller Endbenutzer

Kontext

Wenn Sie IAS verwenden, verfügen Sie in der Regel über einen Mandanten für die Produktionsumgebung und einen Mandanten für die Entwicklungs-/Testumgebung. Für die verschiedenen Unterkonten oder Anwendungen in BTP können Sie auswählen, welcher Identitätsanbieter (IAS-Mandant) verwendet werden soll.

Unsere Empfehlung

Es wird empfohlen, für alle Interaktionen mit Endbenutzern immer den IAS-Mandanten für die Produktionsumgebung zu verwenden, auch im Kontext einer Entwicklungs-/Testversion oder -umgebung der Anwendung, bei der sich die Endbenutzer anmelden müssen.

Es wird empfohlen, andere IAS-Mandanten nur zum Testen der identitätsbezogenen Konfiguration zu verwenden, die isoliert vom Produktionsmandanten erfolgen muss.

Gründe für diese Empfehlung

Da IAS die zentrale Komponente ist, die für den Verbund mit Microsoft Entra ID eingerichtet wurde, gibt es nur eine einzige Stelle, an der die Verbund- und Identitätskonfiguration eingerichtet und verwaltet werden muss. Eine Duplizierung in andere IAS-Mandanten kann zu Fehlkonfigurationen oder Inkonsistenzen beim Endbenutzerzugriff zwischen Umgebungen führen.

6\. Definition eines Rolloverprozesses für SAML-Signaturzertifikate

Kontext

Beim Konfigurieren des Verbunds zwischen Microsoft Entra ID und IAS sowie zwischen IAS und BTP werden SAML-Metadaten ausgetauscht, die X.509-Zertifikate enthalten. Diese Zertifikate werden für die Verschlüsselung und kryptografische Signaturen der SAML-Token verwendet, die zwischen beiden Parteien gesendet werden. Die Zertifikate verfügen über Ablaufdaten und müssen regelmäßig aktualisiert werden (auch in Notfallsituationen, wenn z. B. ein Zertifikat kompromittiert wurde).

Beachten Sie, dass die Standardgültigkeitsdauer des anfänglichen Microsoft Entra-Zertifikats, das zum Signieren von SAML-Assertionen verwendet wird, 3 Jahre beträgt. (Beachten Sie weiterhin, dass das Zertifikat im Gegensatz zu OpenID Connect- und OAuth 2.0-Token, die von einem globalen Zertifikat in Microsoft Entra ID signiert werden, speziell für die Unternehmensanwendung gilt.) Sie können ein neues Zertifikat mit einem anderen Ablaufdatum generieren oder ein eigenes Zertifikat erstellen und importieren.

Wenn Zertifikate ablaufen, können sie nicht mehr verwendet werden, sodass neue Zertifikate konfiguriert werden müssen. Daher muss ein Prozess eingerichtet werden, um die Zertifikatkonfiguration in der vertrauenden Seite (die die Signaturen überprüfen muss) mit den tatsächlichen Zertifikaten, die zum Signieren der SAML-Token verwendet werden, auf dem aktuellen Stand zu halten.

In einigen Fällen kann die vertrauende Seite dies automatisch erledigen, indem die Konfiguration über einen Metadatenendpunkt bereitgestellt wird, der die aktuellen Metadateninformationen dynamisch zurückgibt. Dafür wird in der Regel eine öffentlich zugängliche URL verwendet, von der die vertrauende Seite die Metadaten in regelmäßigen Abständen abrufen und ihren internen Konfigurationsspeicher aktualisieren kann.

Allerdings lässt IAS nur die Einrichtung von Unternehmensidentitätsanbietern durch einen Import der XML-Metadatendatei zu. Die Bereitstellung eines Metadatenendpunkts für den dynamischen Abruf der Microsoft Entra-Metadaten (z. B. https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id) wird nicht unterstützt. Ebenso lässt BTP keine Einrichtung einer neuen Vertrauensstellungskonfiguration über den IAS-Metadatenendpunkt (z. B. https://my-ias-tenant.accounts.ondemand.com/saml2/metadata) zu. Es ist ebenfalls ein einmaliger Upload einer XML-Metadatendatei erforderlich.

Unsere Empfehlung

Stellen Sie beim Einrichten des Identitätsverbunds zwischen zwei Systemen (z. B. Microsoft Entra ID und IAS sowie IAS und BTP) sicher, dass Sie das Ablaufdatum der verwendeten Zertifikate erfassen. Stellen Sie sicher, dass diese Zertifikate rechtzeitig ersetzt werden können und dass ein dokumentierter Prozess zum Aktualisieren der neuen Metadaten in allen vertrauenden Seiten vorhanden ist, die von diesen Zertifikaten abhängig sind.

Wie bereits erwähnt, wird die Einrichtung einer Vertrauensstellungskonfiguration in BTP für IAS empfohlen, die wiederum für den Verbund mit Microsoft Entra ID als Unternehmensidentitätsanbieter eingerichtet ist. In diesem Fall sind die folgenden Zertifikate (die für die SAML-Signatur und Verschlüsselung verwendet werden) wichtig:

  • Das Unterkontozertifikat in BTP: Wenn sich dieses Zertifikat ändert, muss die SAML 2.0-Konfiguration der Anwendung in IAS aktualisiert werden.
  • Das Mandantenzertifikat in IAS: Wenn sich dieses Zertifikat ändert, müssen sowohl die SAML 2.0-Konfiguration der Unternehmensanwendung in Microsoft Entra ID als auch die Vertrauensstellungskonfiguration in BTP aktualisiert werden.
  • Das Unternehmensanwendungszertifikat in Microsoft Entra ID: Wenn sich dieses Zertifikat ändert, muss die SAML 2.0-Konfiguration des Unternehmensidentitätsanbieters in IAS aktualisiert werden.

Rollover von SAML-Signaturzertifikaten

SAP stellt Beispielimplementierungen für Clientzertifikatbenachrichtigungen mit SAP Cloud Integration und für in Kürze ablaufende Zertifikate bereit. Diese können mit Azure Integration Services oder PowerAutomate angepasst werden. Sie müssen jedoch für die Verwendung von Serverzertifikaten angepasst werden. Dafür ist eine benutzerdefinierte Implementierung erforderlich.

Gründe für diese Empfehlung

Wenn die Zertifikate ablaufen dürfen oder rechtzeitig ersetzt werden, aber die von den Zertifikaten abhängigen vertrauenden Seiten nicht mit den neuen Zertifikatinformationen aktualisiert werden, können sich Benutzer nicht mehr über den Verbund bei Anwendungen anmelden. Dies kann zu erheblichen Ausfallzeiten für alle Benutzer führen, während der Dienst durch Neukonfiguration der Metadaten wiederhergestellt wird.

Zusammenfassung der Implementierung

Fügen Sie eine E-Mail-Benachrichtigungsadresse für den Zertifikatablauf in Microsoft Entra ID hinzu, und legen Sie sie auf ein Gruppenpostfach fest, damit die Benachrichtigung nicht an eine einzelne Person gesendet wird (die beim Ablauf des Zertifikats möglicherweise sogar kein Konto mehr hat). Standardmäßig erhält nur der Benutzer, der die Unternehmensanwendung erstellt hat, eine Benachrichtigung.

Erwägen Sie eine Automatisierung, um den gesamten Rolloverprozess für Zertifikat auszuführen. Sie können z. B. regelmäßig überprüfen, ob Zertifikate ablaufen, und diese ersetzen, während alle vertrauenden Seiten mit den neuen Metadaten aktualisiert werden.

Verwenden von Azure AD B2C als Identitätsanbieter

Azure Active Directory B2C stellt die Business-to-Customer-Identität als Dienst bereit. Da die Integration in Azure AD B2C mit der Anmeldung von Unternehmensbenutzern bei Microsoft Entra ID vergleichbar ist, gelten die oben genannten Empfehlungen größtenteils immer noch, wenn Sie Azure AD B2C für Ihre Kunden, Consumer oder Bürger verwenden und ihnen die Verwendung ihrer bevorzugten Identitäten für soziale Netzwerke, Unternehmen oder lokale Konten ermöglichen.

Es gibt jedoch einige wichtige Unterschiede. Das Einrichten von Azure AD B2C als Unternehmensidentitätsanbieter in IAS und das Konfigurieren des Verbunds zwischen beiden Mandanten wird in diesem Blogbeitrag ausführlicher beschrieben.

Registrieren einer SAML-Anwendung in Azure AD B2C

Für Azure AD B2C gibt es keinen Katalog von Unternehmensanwendungen, mit denen Sie die Vertrauensstellung zum Unternehmensidentitätsanbieter in IAS einfach konfigurieren können. Stattdessen müssen Sie benutzerdefinierte Richtlinien verwenden, um in Azure AD B2C eine SAML-Anwendung zu registrieren. Diese SAML-Anwendung spielt jedoch die gleiche logische Rolle wie die Unternehmensanwendung in Microsoft Entra ID, sodass beispielsweise die gleiche Anleitung zum Rollover von SAML-Zertifikaten gilt.

Autorisierung mit Azure AD B2C

Azure AD B2C unterstützt nicht nativ die Verwendung von Gruppen zum Erstellen von Benutzersammlungen, denen Sie Zugriff zuweisen können. Dies bedeutet, dass die Anleitung zur Verwendung von Microsoft Entra-Gruppen für die Autorisierung über Rollensammlungen in BTP anders implementiert werden muss.

Glücklicherweise ist Azure AD B2C hochgradig anpassbar, sodass Sie die SAML-Token konfigurieren können, die Azure AD B2C an IAS sendet, um benutzerdefinierte Informationen einzubeziehen. Verschiedene Optionen zur Unterstützung von Autorisierungsansprüchen finden Sie in der Dokumentation zum Beispiel für Azure AD B2C-App-Rollen, aber zusammengefasst gilt: Über den API-Connector-Erweiterbarkeitsmechanismus können Sie optional weiterhin Gruppen, App-Rollen oder sogar eine benutzerdefinierte Datenbank verwenden, um zu bestimmen, worauf der Benutzer zugreifen darf.

Unabhängig davon, woher die Autorisierungsinformationen stammen, können sie als Groups-Attribut innerhalb des SAML-Tokens ausgegeben werden, indem dieser Attributname als Standard-Partneranspruchstyp im Anspruchsschema konfiguriert oder der Partneranspruchstyp für die Ausgabeansprüche überschrieben wird. Beachten Sie jedoch, dass BTP Ihnen erlaubt, Rollensammlungen Benutzerattributen zuzuordnen, was bedeutet, dass jeder Attributname für Berechtigungsentscheidungen verwendet werden kann, auch wenn Sie den Groups-Attributnamen nicht verwenden.

Nächste Schritte