Tutorial: Konfigurieren der Ping-Identität mit Azure Active Directory B2C für einen sicheren Hybridzugriff

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

In diesem Tutorial erfahren Sie, wie Sie die Funktionen von Azure Active Directory B2C (Azure AD B2C) mit PingAccess und PingFederate erweitern. PingAccess bietet Zugriff auf Anwendungen und APIs sowie eine Richtlinien-Engine für den Zugriff autorisierter Benutzer. PingFederate ist ein Unternehmensverbundserver für Benutzerauthentifizierung und Single Sign-On, eine Berechtigung, die Kunden, Mitarbeitern und Partnern den Zugriff auf Anwendungen von Geräten aus ermöglicht. Verwenden Sie sie zusammen, um einen sicheren Hybridzugriff (Hybrid Access, SHA) zu ermöglichen.

Viele E-Commerce-Websites und Webanwendungen, die dem Internet ausgesetzt sind, werden hinter Proxy-Systemen oder einem Reverse-Proxy-System bereitgestellt. Diese Proxy-Systeme authentifizieren sich vorab, setzen Richtlinien durch und leiten den Datenverkehr weiter. Typische Szenarien sind der Schutz von Webanwendungen vor eingehendem Webdatenverkehr und die Bereitstellung einer einheitlichen Sitzungsverwaltung für verteilte Serverbereitstellungen.

Im Allgemeinen enthalten Konfigurationen eine Authentifizierungsübersetzungsschicht, die die Authentifizierung aus der Webanwendung externalisiert. Reverseproxys stellen den Webanwendungen den Kontext der authentifizierten Person zur Verfügung, beispielsweise einen Headerwert im Nur-Text- oder Digestformat. Die Anwendungen verwenden keine branchenüblichen Token wie Security Assertion Markup Language (SAML), OAuth oder OpenID Connect (OIDC). Stattdessen stellt der Proxy den Authentifizierungskontext bereit und verwaltet die Sitzung mit dem Endbenutzer-Agent, z. B. dem Browser oder der nativen Anwendung. Als Dienst, der als Man-in-the-Middle arbeitet, bieten Proxys eine erhebliche Sitzungssteuerung. Der Proxydienst ist effizient und skalierbar und stellt keinen Engpass für Anwendungen hinter dem Proxydienst dar. Das Diagramm zeigt eine Reverse-Proxy-Implementierung und den Kommunikationsfluss.

Modernisierung

Wenn Sie eine Identitätsplattform in solchen Konfigurationen modernisieren möchten, gibt es möglicherweise Bedenken der Kunden:

• Entkoppeln Sie den Aufwand für die Modernisierung von Anwendungen von der Modernisierung einer Identitätsplattform
• Umgebungen mit moderner Authentifizierung und Legacyauthentifizierung, die den modernisierten Identitätsdienstanbieter nutzen
  • Fördern Sie die Konsistenz der Endbenutzererfahrung
  • Bereitstellen einer einmaligen Anmeldung für alle Anwendungen

Als Antwort auf diese Bedenken ist der Ansatz in diesem Tutorial eine Integration von Azure AD B2C, PingAccess und PingFederate .

Gemeinsame Umgebung

Eine technisch praktikable und kostengünstige Lösung besteht darin, das Reverseproxy-System so zu konfigurieren, dass es das modernisierte Identitätssystem verwendet und die Authentifizierung delegiert.
Proxys unterstützen die modernen Authentifizierungsprotokolle und verwenden die umleitungsbasierte (passive) Authentifizierung, die Benutzer an den neuen Identitätsanbieter (IdP) sendet.

Azure AD B2C als Identitätsanbieter

In Azure AD B2C definieren Sie Richtlinien, die Benutzererfahrungen und -verhaltensweisen steuern, die auch als User Journeys bezeichnet werden. Jede dieser Richtlinien macht einen Protokollendpunkt verfügbar, der die Authentifizierung als IdP ausführen kann. Auf der Anwendungsseite ist für bestimmte Richtlinien keine besondere Behandlung erforderlich. Eine Anwendung sendet eine Standardauthentifizierungsanforderung an den protokollspezifischen Authentifizierungsendpunkt, der durch eine Richtlinie verfügbar gemacht wird.
Sie können Azure AD B2C so konfigurieren, dass für jede Richtlinie derselbe Aussteller oder ein eindeutiger Aussteller für jede Richtlinie verwendet wird. Jede Anwendung kann auf Richtlinien verweisen, indem sie eine protokollnative Authentifizierungsanforderung stellt, die das Benutzerverhalten wie Anmeldung, Registrierung und Profilbearbeitung steuert. Das Diagramm zeigt die Arbeitsabläufe von OIDC- und SAML-Anwendungen.

Das Szenario kann für die Legacyanwendungen eine Herausforderung darstellen, den Benutzer genau umzuleiten. Die Zugriffsanforderung für die Anwendungen enthält möglicherweise nicht den Kontext der Benutzererfahrung. In den meisten Fällen fängt die Proxy-Schicht oder ein integrierter Agent in der Webanwendung die Zugriffsanforderung ab.

PingAccess-Reverseproxy

Sie können PingAccess als Reverseproxy bereitstellen. PingAccess fängt eine direkte Anforderung ab, indem der Dienst als Vermittler (Man-in-the-Middle) oder Umleitung von einem auf dem Webanwendungsserver ausgeführten Agent fungiert.

Konfigurieren Sie PingAccess mit OIDC, OAuth2 oder SAML für die Authentifizierung mit einem Upstream-Authentifizierungsanbieter. Zu diesem Zweck können Sie auf dem PingAccess-Server einen Upstream-IdP konfigurieren. Sehen Sie sich das folgende Diagramm an.

In einer typischen Azure AD B2C-Bereitstellung mit Richtlinien, die IdPs verfügbar machen, besteht eine Herausforderung. PingAccess ist mit einem Upstream-IdP konfiguriert.

PingFederate-Verbundproxy

Sie können PingFederate als Authentifizierungsanbieter oder Proxy für Upstream-IdPs konfigurieren. Sehen Sie sich das folgende Diagramm an.

Verwenden Sie diese Funktion, um eine eingehende Anforderung kontextbezogen, dynamisch oder deklarativ zu einer Azure AD B2C-Richtlinie zu wechseln. Sehen Sie sich das folgende Diagramm des Ablaufs der Protokollsequenz an.

Voraussetzungen

Zunächst benötigen Sie Folgendes:

• Azure-Abonnement
  • Wenn Sie kein Konto haben, erhalten Sie ein kostenloses Azure-Konto.
• Einen Azure AD B2C-Mandanten, der mit Ihrem Azure-Abonnement verknüpft ist
• PingAccess und PingFederate werden in Docker-Containern oder auf virtuellen Azure-Computern (VMs) bereitgestellt

Konnektivität und Kommunikation

Bestätigen Sie die folgende Konnektivität und Kommunikation.

• PingAccess-Server: Kommuniziert mit dem PingFederate-Server, Clientbrowser, OIDC und OAuth (bekannt) und ermittelt Schlüssel, die vom Azure AD B2C-Dienst und PingFederate-Server veröffentlicht werden.
• PingFederate-Server: Kommuniziert mit dem PingAccess-Server, Clientbrowser, OIDC und OAuth (bekannt) und ermittelt Schlüssel, die vom Azure AD B2C-Dienst veröffentlicht werden.
• Legacy- oder Header-basierte AuthN-Anwendung – Kommuniziert mit und zum PingAccess-Server
• SAML-Anwendung der vertrauenden Seite: Erreicht den vom Client stammenden Browserdatenverkehr. Greift auf die SAML-Verbundmetadaten zu, die vom Azure AD B2C-Dienst veröffentlicht wurden.
• Moderne Anwendung – Erreicht den Browserverkehr vom Client. Greift auf OIDC und OAuth (bekannt) zu und ermittelt Schlüssel, die vom Azure AD B2C-Dienst veröffentlicht werden.
• REST-API: Erreicht den von einem nativen oder Webclient stammenden Datenverkehr. Greift auf OIDC und OAuth (bekannt) zu und ermittelt Schlüssel, die vom Azure AD B2C-Dienst veröffentlicht werden.

Konfigurieren von Azure AD B2C

Sie können grundlegende Benutzerflows oder erweiterte IEF-Richtlinien (Identity Enterprise Framework) verwenden. PingAccess generiert den Metadatenendpunkt basierend auf dem Ausstellerwert mithilfe des WebFinger-Protokolls für die Ermittlungskonvention. Um diese Konvention einzuhalten, aktualisieren Sie den Azure AD B2C-Aussteller mithilfe von Richtlinieneigenschaften in Benutzerflows.

In den erweiterten Richtlinien umfasst die Konfiguration das auf den Wert „AuthorityWithTfp“ festgelegte IssuanceClaimPattern-Metadatenelement im technischen Profil des JWT-Ausstellers.

Konfigurieren von PingAccess und PingFederate

Verwenden Sie die Anweisungen in den folgenden Abschnitten, um PingAccess und PingFederate zu konfigurieren. Sehen Sie sich das folgende Diagramm des gesamten Benutzerablaufs für die Integration an.

Konfigurieren von PingFederate als Tokenanbieter

Um PingFederate als Tokenanbieter für PingAccess zu konfigurieren, stellen Sie sicher, dass die Konnektivität von PingFederate zu PingAccess hergestellt wird. Bestätigen Sie die Verbindung von PingAccess zu PingFederate.

Konfigurieren einer PingAccess-Anwendung für die headerbasierte Authentifizierung

Verwenden Sie die folgenden Anweisungen, um eine PingAccess-Anwendung für die Zielwebanwendung für die headerbasierte Authentifizierung zu erstellen.

Erstellen eines virtuellen Hosts

Von Bedeutung

Erstellen Sie für jede Anwendung einen virtuellen Host.

So erstellen Sie einen virtuellen Host:

1. Gehen Sie zu Einstellungen>Zugriff auf>virtuelle Hosts.
2. Wählen Sie Virtuellen Host hinzufügen aus.
3. Geben Sie unter Host den FQDN-Teil der Anwendungs-URL ein.
4. Geben Sie als Port den Wert 443 ein.
5. Wählen Sie Speichern aus.

Erstellen einer Websitzung

So erstellen Sie eine Websitzung:

1. Navigieren Sie zu Einstellungen>für den Zugriff>auf Websitzungen.
2. Wählen Sie Websitzung hinzufügen aus.
3. Geben Sie einen Namen für die Websitzung ein.
4. Wählen Sie den Cookie-Typ aus: signiertes JWT oder verschlüsseltes JWT.
5. Geben Sie einen eindeutigen Wert für Zielgruppe ein.
6. Geben Sie als Client-ID die Microsoft Entra Application ID ein.
7. Geben Sie für Client Secret den Schlüssel ein, den Sie für die Anwendung in Microsoft Entra ID generiert haben.
8. (Fakultativ) Erstellen und Verwenden von benutzerdefinierten Ansprüchen mit der Microsoft Graph-API: Wählen Sie Erweitert aus. Deaktivieren Sie Profil anfordern und Benutzerattribute aktualisieren. Weitere Informationen zu benutzerdefinierten Ansprüchen finden Sie unter Headerbasiertes einmaliges Anmelden für lokale Apps mit dem Microsoft Entra-Anwendungsproxy.
9. Wählen Sie "Speichern" aus.

Erstellen der Identitätszuordnung

Hinweis

Sie können die Identitätszuordnung mit mehr als einer Anwendung verwenden, wenn diese dieselben Daten im Header erwarten.

So erstellen Sie die Identitätszuordnung

1. Wechseln Sie zu Einstellungen>für den Zugriff auf>Identitätszuordnungen.
2. Wählen Sie Identitätszuordnung hinzufügen aus.
3. Geben Sie *einen Namen an.
4. Wählen Sie die Identitätszuordnung Identitätszuordnung: Headertyp aus.
5. Geben Sie in der Tabelle Attributzuordnung die erforderlichen Zuordnungen an. Beispiel:

Attributname	Kopfzeilenname
"UPN"	X-BenutzerPrinzipalName
"email"	X-E-Mail
'oid'	X-OID
'SCP'	X-Zielfernrohr
"AMR"	X-AMR

6. Wählen Sie "Speichern" aus.

Erstellen einer Website

Hinweis

In einigen Konfigurationen kann eine Site mehrere Anwendungen enthalten. Sie können bei Bedarf eine Website mit mehr als einer Anwendung verwenden.

So erstellen Sie eine Website:

1. Gehen Sie zu den Hauptseiten>.
2. Wählen Sie Website hinzufügen aus.
3. Geben Sie den Namen der Website ein.
4. Geben Sie die Target-Website ein. Das Ziel ist das Hostname:Port-Paar für den Server, auf dem die Anwendung gehostet wird. Geben Sie den Anwendungspfad nicht in dieses Feld ein. Eine Anwendung at https://mysite:9999/AppName hat z. B. den Zielwert mysite:9999.
5. Geben Sie an, ob das Ziel sichere Verbindungen erwartet.
6. Wenn das Ziel sichere Verbindungen erwartet, legen Sie die vertrauenswürdige Zertifikatsgruppe auf "Vertrauenswürdig beliebig" fest.
7. Wählen Sie Speichern aus.

Erstellen einer Anwendung

Erstellen einer Anwendung in PingAccess für jede Anwendung in Azure, die Sie schützen möchten.

1. Zu den Hauptanwendungen>

2. Wählen Sie Add Application (Anwendung hinzufügen) aus.

3. Geben Sie einen Namen für die Anwendung an.

4. Geben Sie optional eine Beschreibung für die Anwendung ein

5. Geben Sie den Kontextstamm für die Anwendung an. Eine Anwendung unter https://mysite:9999/AppName hat z. B. den Kontextstamm /AppName. Der Kontextstamm muss mit einem Schrägstrich (/) beginnen, darf nicht mit einem Schrägstrich (/) enden und kann mehr als eine Ebene tief sein, z. B. /Apps/MyApp.

6. Wählen Sie den virtuellen Host aus, den Sie erstellt haben

   Hinweis

   Die Kombination aus virtuellem Host und Kontextstamm muss in PingAccess eindeutig sein.

7. Wählen Sie die Websitzung aus, die Sie erstellt haben

8. Wählen Sie die von Ihnen erstellte Website aus, die die Anwendung enthält

9. Wählen Sie die von Ihnen erstellte Identitätszuordnung aus

10. Wählen Sie Aktiviert aus, um die Website beim Speichern zu aktivieren

11. Wählen Sie "Speichern" aus.

Konfigurieren der Authentifizierungsrichtlinie von PingFederate

Konfigurieren Sie die PingFederate-Authentifizierungsrichtlinie so, dass ein Verbund mit den mehreren IdPs hergestellt wird, die von den Azure AD B2C-Mandanten bereitgestellt werden

1. Richten Sie einen Vertrag zur Überbrückung der Attribute zwischen den Identitätsanbietern und dem Dienstanbieter ein. Sie sollten nur einen Vertrag benötigen, es sei denn, der SP erfordert einen anderen Satz von Attributen von jedem IdP. Weitere Informationen finden Sie unter Verbundhub und Authentifizierungsrichtlinienverträge in der Ping Identity-Dokumentation.

2. Erstellen Sie für jeden IdP eine IdP-Verbindung zwischen dem IdP und PingFederate, dem Verbundhub als SP.

3. Fügen Sie im Fenster Zielsitzungszuordnung die betreffenden Authentifizierungsrichtlinienverträge für die Verbindung mit dem Identitätsanbieter hinzu.

4. Konfigurieren Sie im Fenster Selektoren einen Authentifizierungsselektor. Sehen Sie sich z. B. eine Instanz des Identifier First Adapter an, um jeden IdP der entsprechenden IdP-Verbindung in einer Authentifizierungsrichtlinie zuzuordnen.

5. Erstellen Sie eine SP-Verbindung zwischen PingFederate, dem Verbundhub als IdP und dem SP.

6. Fügen Sie der SP-Verbindung im Fenster Authentifizierungsquellenzuordnung den entsprechenden Authentifizierungsrichtlinienvertrag hinzu.

7. Arbeiten Sie mit den einzelnen Identitätsanbietern zusammen, um eine Verbindung mit PingFederate und mit dem Verbundhub als Dienstanbieter herzustellen.

8. Arbeiten Sie mit dem Dienstanbieter zusammen, um eine Verbindung mit PingFederate mit dem Verbundhub als Identitätsanbieter herzustellen.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln

• Benutzerdefinierte Richtlinien in Azure AD B2C

• Erste Schritte mit benutzerdefinierten Richtlinien in Azure AD B2C