Anleitung: Migration vom Azure Access Control Service

Microsoft Azure Access Control Service (ACS), ein Dienst von Azure Active Directory (Azure AD), wird am 7. November 2018 eingestellt. Anwendungen und Dienste, die derzeit die Zugriffssteuerung verwenden, müssen dann vollständig zu einem anderen Authentifizierungsmechanismus migriert werden. In diesem Artikel werden Empfehlungen für aktuelle Kunden beschrieben, da Sie beabsichtigen, Die Verwendung der Zugriffssteuerung zu deaktivieren. Wenn Sie derzeit keine Zugriffssteuerung verwenden, müssen Sie keine Maßnahmen ergreifen.

Überblick

Die Zugriffssteuerung ist ein Cloudauthentifizierungsdienst, der eine einfache Möglichkeit bietet, Benutzer für den Zugriff auf Ihre Webanwendungen und Dienste zu authentifizieren und zu autorisieren. Sie ermöglicht es, viele Funktionen der Authentifizierung und Autorisierung aus Ihrem Code auszulagern. Die Zugriffssteuerung wird in erster Linie von Entwicklern und Architekten von Microsoft .NET-Clients, ASP.NET Webanwendungen und WCF-Webdiensten (Windows Communication Foundation) verwendet.

Anwendungsfälle für die Zugriffssteuerung können in drei Hauptkategorien unterteilt werden:

• Authentifizieren für bestimmte Microsoft-Clouddienste, einschließlich Azure Service Bus und Dynamics CRM. Clientanwendungen rufen Token von der Zugriffssteuerung ab, um sich bei diesen Diensten zu authentifizieren, um verschiedene Aktionen auszuführen.
• Hinzufügen der Authentifizierung zu Webanwendungen, sowohl benutzerdefinierte als auch vorgepackt (z. B. SharePoint). Mithilfe der "passiven" Authentifizierung der Zugriffssteuerung können Webanwendungen die Anmeldung mit einem Microsoft-Konto (früher Live ID) und mit Konten von Google, Facebook, Yahoo, Azure AD und Active Directory Federation Services (AD FS) unterstützen.
• Schützen benutzerdefinierter Webdienste mit Token, die von der Zugriffssteuerung ausgestellt wurden. Mithilfe der "aktiven" Authentifizierung können Webdienste sicherstellen, dass sie nur auf bekannte Clients zugreifen können, die sich mit der Zugriffssteuerung authentifiziert haben.

Jede dieser Anwendungsfälle und ihre empfohlenen Migrationsstrategien werden in den folgenden Abschnitten erläutert.

Die Zugriffssteuerung verfügt über die folgenden Komponenten:

• Ein sicherer Tokendienst (Secure Token Service, STS), der Authentifizierungsanforderungen empfängt und Sicherheitstoken zurückgibt.
• Das klassische Azure-Portal, in dem Sie Namespaces für die Zugriffssteuerung erstellen, löschen und aktivieren und deaktivieren.
• Ein separates Zugriffssteuerungsverwaltungsportal, in dem Sie Access Control-Namespaces anpassen und konfigurieren.
• Ein Verwaltungsdienst, mit dem Sie die Funktionen der Portale automatisieren können.
• Eine Tokentransformationsregel-Engine, mit der Sie komplexe Logik definieren können, um das Ausgabeformat von Token zu bearbeiten, die von der Zugriffskontrolle ausgegeben werden.

Um diese Komponenten zu verwenden, müssen Sie einen oder mehrere Access Control-Namespaces erstellen. Ein Namespace ist eine dedizierte Instanz der Zugriffssteuerung, mit der Ihre Anwendungen und Dienste kommunizieren. Ein Namespace ist von allen anderen Zugriffssteuerungskunden isoliert. Andere Zugriffssteuerungskunden verwenden ihre eigenen Namespaces. Ein Namespace in access Control verfügt über eine dedizierte URL, die wie folgt aussieht:

https://<mynamespace>.accesscontrol.windows.net

Sämtliche Kommunikation mit den STS sowie die Durchführung von Verwaltungsvorgängen erfolgt über diese URL. Sie verwenden unterschiedliche Pfade für unterschiedliche Zwecke. Um festzustellen, ob Ihre Anwendungen oder Dienste die Zugriffssteuerung verwenden, überwachen Sie den Datenverkehr auf https://< namespace.accesscontrol.windows.net>. Jeder Datenverkehr zu dieser URL wird von der Zugriffssteuerung behandelt und muss eingestellt werden.

Die Ausnahme hierfür ist jeglicher Netzwerkverkehr zu https://accounts.accesscontrol.windows.net. Der Datenverkehr zu dieser URL wird bereits von einem anderen Dienst verarbeitet und ist von der Deaktivierung der Zugriffssteuerung nicht betroffen.

Weitere Informationen zur Zugriffssteuerung finden Sie unter Access Control Service 2.0 (archiviert).

Herausfinden, welche Ihrer Apps betroffen sind

Führen Sie die Schritte in diesem Abschnitt aus, um herauszufinden, welche Ihrer Apps durch die Einstellung von ACS beeinträchtigt werden.

Herunterladen und Installieren von ACS PowerShell

1. Wechseln Sie zum PowerShell-Katalog, und laden Sie Acs.Namespaces herunter.

2. Installieren des Moduls durch Ausführen

   Install-Module -Name Acs.Namespaces
   

3. Erhalten Sie eine Liste aller möglichen Befehle, indem Sie ausführen.

   Get-Command -Module Acs.Namespaces
   

   Um Hilfe zu einem bestimmten Befehl zu erhalten, führen Sie Folgendes aus:

    Get-Help [Command-Name] -Full
   

   bei [Command-Name] handelt es sich um den Namen des ACS-Befehls.

Listen Sie Ihre ACS-Namespaces auf

1. Stellen Sie mithilfe des Cmdlets Connect-AcsAccount eine Verbindung mit ACS her.

   Möglicherweise müssen Sie Set-ExecutionPolicy -ExecutionPolicy Bypass ausführen, bevor Sie Befehle ausführen können und um als Administrator dieser Abonnements die Befehle auszuführen.

2. Listen Sie Ihre verfügbaren Azure-Abonnements mit dem Cmdlet Get-AcsSubscription auf .

3. Listen Sie Ihre ACS-Namespaces mithilfe des Cmdlets "Get-AcsNamespace " auf.

Überprüfen, welche Anwendungen betroffen sind

1. Verwenden Sie den Namespace aus dem vorherigen Schritt, und wechseln Sie zu https://<namespace>.accesscontrol.windows.net

   Wenn beispielsweise einer der Namespaces "contoso-test" ist, wechseln Sie zu https://contoso-test.accesscontrol.windows.net

2. Wählen Sie unter "Vertrauensstellungen" die Option "Vertrauensanwendungen" aus, um die Liste der Apps anzuzeigen, die von der Einstellung von ACS betroffen sind.

3. Wiederholen Sie die Schritte 1 bis 2 für alle anderen ACS-Namespaces, die Sie haben.

Ruhestandszeitplan

Seit November 2017 werden alle Access Control-Komponenten vollständig unterstützt und betriebsbereit. Die einzige Einschränkung besteht darin, dass Sie keine neuen Zugriffssteuerungsnamespaces über das klassische Azure-Portal erstellen können.

Hier finden Sie den Zeitplan für die Abschaffung von Zugriffssteuerungskomponenten.

• November 2017: Die Azure AD-Administratorerfahrung im klassischen Azure-Portal wird eingestellt. Zu diesem Zeitpunkt steht die Namespaceverwaltung für die Zugriffssteuerung unter einer neuen dedizierten URL zur Verfügung: https://manage.windowsazure.com?restoreClassic=true. Verwenden Sie diese URL, um Ihre vorhandenen Namespaces anzuzeigen, Namespaces zu aktivieren und zu deaktivieren und Namespaces zu löschen, wenn Sie dies auswählen.
• 2. April 2018: Das klassische Azure-Portal ist vollständig eingestellt, was bedeutet, dass die Verwaltung des Zugriffssteuerungsnamespaces nicht mehr über eine URL verfügbar ist. An diesem Punkt können Sie Ihre Access Control-Namespaces nicht deaktivieren oder aktivieren, löschen oder aufzählen. Das Verwaltungsportal für die Zugriffssteuerung ist jedoch voll funktionsfähig und befindet sich unter https://<namespace>.accesscontrol.windows.net. Alle anderen Komponenten der Zugriffssteuerung funktionieren weiterhin normal.
• 7. November 2018: Alle Access Control-Komponenten werden dauerhaft heruntergefahren. Dazu gehören das Zugriffssteuerungsverwaltungsportal, der Verwaltungsdienst, STS und das Tokentransformationsregelmodul. An diesem Punkt schlagen alle Anforderungen, die an die Zugriffssteuerung gesendet werden (unter <namespace>.accesscontrol.windows.net) fehl. Sie sollten alle vorhandenen Apps und Dienste bereits vor diesem Zeitpunkt zu anderen Technologien migriert haben.

Migrationsstrategien

In den folgenden Abschnitten werden allgemeine Empfehlungen für die Migration von Access Control zu anderen Microsoft-Technologien beschrieben.

Clients von Microsoft Cloud Services

Jeder Microsoft-Clouddienst, der Token akzeptiert, die von der Zugriffssteuerung ausgestellt werden, unterstützt jetzt mindestens eine alternative Authentifizierungsform. Der richtige Authentifizierungsmechanismus variiert je nach Dienst. Wir empfehlen, dass Sie sich auf die spezifische Dokumentation für jeden Dienst beziehen, um offizielle Anleitungen zu erhalten. Aus Gründen der Einfachheit wird jeder Satz von Dokumentationen hier bereitgestellt:

SharePoint-Kunden

SharePoint 2013-, 2016- und SharePoint Online-Kunden haben ACS für Authentifizierungszwecke in Cloud-, lokalen und Hybridszenarien verwendet. Einige SharePoint-Features und Anwendungsfälle werden durch die Abschaffung von ACS beeinflusst, während andere nicht betroffen sind. Die folgende Tabelle enthält eine Zusammenfassung der Migrationsanleitungen für einige der am häufigsten verwendeten SharePoint-Features, die ACS nutzen:

Webanwendungen, die passive Authentifizierung verwenden

Für Webanwendungen, die Die Zugriffssteuerung für die Benutzerauthentifizierung verwenden, bietet Access Control die folgenden Features und Funktionen für Webanwendungsentwickler und Architekten:

• Umfassende Integration in Windows Identity Foundation (WIF).
• Integration mit Konten von Google, Facebook, Yahoo, Azure Active Directory, AD FS und Microsoft.
• Unterstützung für die folgenden Authentifizierungsprotokolle: OAuth 2.0 Draft 13, WS-Trust und Web Services Federation (WS-Federation).
• Unterstützung für die folgenden Tokenformate: JSON Web Token (JWT), SAML 1.1, SAML 2.0 und Simple Web Token (SWT).
• Eine in WIF integrierte Home Realm Discovery-Erfahrung, mit der Benutzer den Kontotyp auswählen können, den sie für die Anmeldung verwenden. Diese Oberfläche wird von der Webanwendung gehostet und kann vollständig angepasst werden.
• Tokentransformation, die umfassende Anpassungsmöglichkeiten der von der Zugriffssteuerung an die Webanwendung übermittelten Claims ermöglicht, einschließlich:
  • Ansprüche von Identitätsanbietern durchleiten.
  • Hinzufügen zusätzlicher benutzerdefinierter Ansprüche.
  • Einfache If-then-Logik zum Ausgeben von Ansprüchen unter bestimmten Bedingungen.

Leider gibt es keinen Dienst, der all diese äquivalenten Funktionen bietet. Sie sollten die benötigten Funktionen der Zugriffssteuerung auswerten und dann zwischen der Verwendung von Microsoft Entra ID, Azure Active Directory B2C (Azure AD B2C ) oder einem anderen Cloudauthentifizierungsdienst wählen.

Migrieren zur Microsoft Entra-ID

Ein zu berücksichtigener Weg ist die direkte Integration Ihrer Apps und Dienste mit der Microsoft Entra-ID. Microsoft Entra ID ist der cloudbasierte Identitätsanbieter für Microsoft Geschäfts- oder Schulkonten. Microsoft Entra ID ist der Identitätsanbieter für Microsoft 365, Azure und vieles mehr. Sie bietet ähnliche Verbundauthentifizierungsfunktionen für die Zugriffssteuerung, unterstützt aber nicht alle Zugriffssteuerungsfunktionen.

Das primäre Beispiel ist der Partnerverbund mit Sozialen Identitätsanbietern, z. B. Facebook, Google und Yahoo. Wenn sich Ihre Benutzer mit diesen Arten von Anmeldeinformationen anmelden, ist Microsoft Entra ID nicht die Lösung für Sie.

Die Microsoft Entra-ID unterstützt nicht unbedingt dieselben Authentifizierungsprotokolle wie die Zugriffssteuerung. Obwohl z. B. sowohl die Zugriffssteuerung als auch die Microsoft Entra-ID OAuth unterstützen, gibt es subtile Unterschiede zwischen den einzelnen Implementierungen. Für unterschiedliche Implementierungen müssen Sie Code als Teil einer Migration ändern.

Microsoft Entra ID bietet jedoch mehreren Access Control Kunden potenzielle Vorteile. Es unterstützt systemeigene Microsoft-Geschäfts- oder Schulkonten, die in der Cloud gehostet werden, die häufig von Access Control-Kunden verwendet werden.

Ein Microsoft Entra-Mandant kann auch mit einer oder mehreren Instanzen von lokalen Active Directory über AD FS verbunden werden. Auf diese Weise kann Ihre App cloudbasierte Benutzer und Benutzer authentifizieren, die lokal gehostet werden. Es unterstützt auch das WS-Federation-Protokoll, das die Integration in eine Webanwendung mithilfe von WIF relativ einfach macht.

In der folgenden Tabelle werden die Features der Zugriffssteuerung verglichen, die für Webanwendungen relevant sind, mit den Features, die in der Microsoft Entra-ID verfügbar sind.

Auf hoher Ebene ist Microsoft Entra ID wahrscheinlich die beste Wahl für Ihre Migration, wenn Sie Benutzern erlauben, sich nur mit ihren Microsoft-Geschäfts-, Schul- oder Unikonten anzumelden.

Wenn Sie entscheiden, dass Microsoft Entra-ID der beste Migrationspfad für Ihre Anwendungen und Dienste ist, sollten Sie sich zwei Möglichkeiten zum Integrieren Ihrer App mit Microsoft Entra ID bewusst sein.

Um WS-Federation oder WIF für die Integration in die Microsoft Entra-ID zu verwenden, empfehlen wir, den in "Verbund-Single Sign-On konfigurieren" beschriebenen Ansatz für eine Nicht-Kataloganwendung zu verwenden. Der Artikel bezieht sich auf die Konfiguration der Microsoft Entra-ID für SAML-basiertes Single Sign-On, funktioniert aber auch für die Konfiguration von WS-Federation. Für diese Vorgehensweise ist eine Microsoft Entra ID P1- oder P2-Lizenz erforderlich. Dieser Ansatz hat zwei Vorteile:

• Sie erhalten die volle Flexibilität der Anpassung von Microsoft Entra-Token. Sie können die Ansprüche anpassen, die von der Microsoft Entra-ID ausgestellt werden, um den Ansprüchen zu entsprechen, die von der Zugriffssteuerung ausgestellt werden. Dies schließt insbesondere den "Benutzer-ID"- oder "Name-Identifier"-Claim ein. Um weiterhin konsistente Benutzer-IDentifier für Ihre Benutzer zu erhalten, nachdem Sie Technologien geändert haben, stellen Sie sicher, dass die von Microsoft Entra ID ausgestellten Benutzer-IDs mit den von der Zugriffssteuerung ausgestellten Benutzer-IDs übereinstimmen.
• Sie können ein tokensignierendes Zertifikat konfigurieren, das für Ihre Anwendung spezifisch ist, und mit einer Lebensdauer, die Sie steuern.

Ein alternativer Ansatz besteht darin, diesem Codebeispiel zu folgen, das geringfügig unterschiedliche Anweisungen zum Einrichten von WS-Federation gibt. In diesem Codebeispiel wird WIF nicht verwendet, sondern die ASP.NET 4.5 OWIN-Middleware. Die Anweisungen für die App-Registrierung gelten jedoch für Apps mit WIF und erfordern keine Microsoft Entra ID P1- oder P2-Lizenz.

Wenn Sie diesen Ansatz auswählen, müssen Sie den Signierschlüsselrollover in der Microsoft Entra-ID verstehen. Bei diesem Ansatz wird der globale Microsoft Entra-Signaturschlüssel verwendet, um Token auszugeben. Standardmäßig aktualisiert WIF die Signaturschlüssel nicht automatisch. Wenn Microsoft Entra ID ihre globalen Signaturschlüssel wechselt, muss Ihre WIF-Implementierung auf die Änderungen vorbereitet sein. Weitere Informationen finden Sie unter Wichtige Informationen zur Umschlüsselung des Signaturschlüssels in Microsoft Entra ID.

Wenn Sie die Integration mit Microsoft Entra ID über die OpenID Connect- oder OAuth-Protokolle durchführen können, empfehlen wir dies. Wir verfügen über umfangreiche Dokumentationen und Anleitungen zur Integration von Microsoft Entra ID in Ihre Webanwendung, die in unserem Microsoft Entra-Entwicklerhandbuch zur Verfügung steht.

Migrieren zu Azure Active Directory B2C

Der andere zu berücksichtigende Migrationspfad ist Azure AD B2C. Azure AD B2C ist ein Cloud-Authentifizierungsdienst, der, wie Access Control, es Entwicklern ermöglicht, ihre Authentifizierungs- und Identitätsverwaltungslogik an einen Cloud-Dienst auszulagern. Es handelt sich um einen kostenpflichtigen Dienst (mit kostenlosen und Premium-Stufen), der für verbraucherorientierte Anwendungen konzipiert ist, die bis zu Millionen aktiver Benutzer haben können.

Wie die Zugriffssteuerung ist eine der attraktivsten Features von Azure AD B2C, dass es viele verschiedene Arten von Konten unterstützt. Mit Azure AD B2C können Sie Benutzer mit ihrem Microsoft-Konto oder facebook, Google, LinkedIn, GitHub- oder Yahoo-Konten und mehr anmelden. Azure AD B2C unterstützt auch "lokale Konten" oder Benutzernamen und Kennwörter, die Benutzer speziell für Ihre Anwendung erstellen. Azure AD B2C bietet außerdem eine umfangreiche Erweiterbarkeit, mit der Sie Ihre Anmeldeflüsse anpassen können.

Azure AD B2C unterstützt jedoch nicht die Breite von Authentifizierungsprotokollen und Tokenformaten, die von Kunden der Zugriffssteuerung benötigt werden. Sie können azure AD B2C auch nicht verwenden, um Token abzurufen und zusätzliche Informationen zum Benutzer vom Identitätsanbieter, Microsoft oder auf andere Weise abzufragen.

In der folgenden Tabelle werden die Features der Zugriffssteuerung verglichen, die für Webanwendungen relevant sind, mit denen, die in Azure AD B2C verfügbar sind. Auf hoher Ebene ist Azure AD B2C wahrscheinlich die richtige Wahl für Ihre Migration, wenn Ihre Anwendung verbraucherseitig ist oder viele verschiedene Arten von Konten unterstützt.

Wenn Sie entscheiden, dass Azure AD B2C der beste Migrationspfad für Ihre Anwendungen und Dienste ist, beginnen Sie mit den folgenden Ressourcen:

• Azure AD B2C-Dokumentation
• Benutzerdefinierte Azure AD B2C-Richtlinien
• Azure AD B2C-Preise

Migrieren Sie zu Ping Identity oder Auth0

In einigen Fällen stellen Sie möglicherweise fest, dass Microsoft Entra ID und Azure AD B2C nicht ausreichen, um die Zugriffssteuerung in Ihren Webanwendungen zu ersetzen, ohne wichtige Codeänderungen vorzunehmen. Einige häufige Beispiele könnten umfassen:

• Webanwendungen, die WIF oder WS-Federation für die Anmeldung mit Social Identity-Anbietern wie Google oder Facebook verwenden.
• Webanwendungen, die eine direkte Federation mit einem Unternehmensidentitätsanbieter über das WS-Federation-Protokoll durchführen.
• Webanwendungen, die das von einem sozialen Identitätsanbieter ausgestellte Zugriffstoken (z. B. Google oder Facebook) als Anspruch in den von Access Control ausgestellten Token erfordern.
• Webanwendungen mit komplexen Tokentransformationsregeln, die von Microsoft Entra ID oder Azure AD B2C nicht reproduziert werden können.
• Webanwendungen mit mehreren Mandanten, die ACS verwenden, um den Partnerverbund für viele verschiedene Identitätsanbieter zentral zu verwalten

In diesen Fällen empfiehlt es sich, Ihre Webanwendung zu einem anderen Cloudauthentifizierungsdienst zu migrieren. Es wird empfohlen, die folgenden Optionen zu untersuchen. Jede der folgenden Optionen bietet Funktionen, die der Zugriffssteuerung ähneln:

Auth0 ist ein flexibler Cloudidentitätsdienst, der allgemeine Migrationsleitlinien für Kunden der Zugriffssteuerung erstellt hat und fast jedes Feature unterstützt, das ACS ausführt.

Ping Identity bietet zwei Lösungen wie ACS. PingOne ist ein Cloudidentitätsdienst, der viele der gleichen Features wie ACS unterstützt, und PingFederate ist ein ähnliches lokales Identitätsprodukt, das mehr Flexibilität bietet. Weitere Informationen zur Verwendung dieser Produkte finden Sie in der ACS-Ruhestandsanleitung von Ping.

Unser Ziel bei der Arbeit mit Ping Identity und Auth0 ist es, sicherzustellen, dass alle Zugriffssteuerungskunden über einen Migrationspfad für ihre Apps und Dienste verfügen, die die Für den Wechsel von der Zugriffssteuerung erforderliche Arbeit minimieren.

Webdienste, die die aktive Authentifizierung verwenden

Für Webdienste, die durch die von Access Control (Zugriffssteuerung) ausgestellten Token gesichert sind, bietet Access Control (Zugriffssteuerung) die folgenden Merkmale und Funktionen:

• Möglichkeit zum Registrieren einer oder mehrerer Dienstidentitäten im Access Control-Namespace. Dienstidentitäten können zum Anfordern von Token verwendet werden.
• Unterstützung für die OAuth WRAP- und OAuth 2.0 Draft 13-Protokolle zum Anfordern von Token mithilfe der folgenden Arten von Anmeldeinformationen:
  • Ein einfaches Kennwort, das für die Dienstidentität erstellt wird
  • Ein signiertes SWT mithilfe eines symmetrischen Schlüssels oder X509-Zertifikats
  • Ein SAML-Token, das von einem vertrauenswürdigen Identitätsanbieter ausgestellt wurde (in der Regel eine AD FS-Instanz)
• Unterstützung für die folgenden Tokenformate: JWT, SAML 1.1, SAML 2.0 und SWT.
• Einfache Tokentransformationsregeln.

Dienstidentitäten in der Zugriffssteuerung werden in der Regel verwendet, um die Server-zu-Server-Authentifizierung zu implementieren.

Migrieren zur Microsoft Entra-ID

Unsere Empfehlung für diesen Authentifizierungsflusstyp besteht darin, zu Microsoft Entra ID zu migrieren. Microsoft Entra ID ist der cloudbasierte Identitätsanbieter für Microsoft Geschäfts- oder Schulkonten. Microsoft Entra ID ist der Identitätsanbieter für Microsoft 365, Azure und vieles mehr.

Sie können auch die Microsoft Entra-ID für die Server-zu-Server-Authentifizierung verwenden, indem Sie die Implementierung der OAuth-Clientanmeldeinformationen von Microsoft Entra nutzen. In der folgenden Tabelle werden die Funktionen der Zugriffssteuerung in der Server-zu-Server-Authentifizierung mit denen verglichen, die in der Microsoft Entra-ID verfügbar sind.

Anleitungen zur Implementierung von Server-zu-Server-Szenarien finden Sie in den folgenden Ressourcen:

• Abschnitt "Service-to-Service" des Microsoft Entra-Entwicklerhandbuchs
• Daemon-Codebeispiel mit einfachen Kennwortclientanmeldeinformationen
• Daemon-Codebeispiel mithilfe von Zertifikatclientanmeldeinformationen

Migrieren Sie zu Ping Identity oder Auth0

In einigen Fällen stellen Sie möglicherweise fest, dass die Microsoft Entra-Clientanmeldeinformationen und die OAuth-Genehmigungsimplementierung nicht ausreichen, um die Zugriffssteuerung in Ihrer Architektur ohne wichtige Codeänderungen zu ersetzen. Einige häufige Beispiele könnten umfassen:

• Server-zu-Server-Authentifizierung mit anderen Tokenformaten als JWTs.
• Server-zu-Server-Authentifizierung mithilfe eines Eingabetokens, das von einem externen Identitätsanbieter bereitgestellt wird.
• Server-zu-Server-Authentifizierung mit Regeln zur Tokentransformation, die von Microsoft Entra ID nicht reproduziert werden können.

In diesen Fällen empfiehlt es sich, Ihre Webanwendung zu einem anderen Cloudauthentifizierungsdienst zu migrieren. Es wird empfohlen, die folgenden Optionen zu untersuchen. Jede der folgenden Optionen bietet Funktionen, die der Zugriffssteuerung ähneln:

Auth0 ist ein flexibler Cloudidentitätsdienst, der allgemeine Migrationsleitlinien für Kunden der Zugriffssteuerung erstellt hat und fast jedes Feature unterstützt, das ACS ausführt.

Diese Abbildung zeigt das Logo von Ping Identity. Ping Identity bietet zwei Lösungen ähnlich wie ACS an. PingOne ist ein Cloudidentitätsdienst, der viele der gleichen Features wie ACS unterstützt, und PingFederate ist ein ähnliches lokales Identitätsprodukt, das mehr Flexibilität bietet. Weitere Informationen zur Verwendung dieser Produkte finden Sie in der ACS-Ruhestandsanleitung von Ping.

Unser Ziel bei der Arbeit mit Ping Identity und Auth0 ist es, sicherzustellen, dass alle Zugriffssteuerungskunden über einen Migrationspfad für ihre Apps und Dienste verfügen, die die Für den Wechsel von der Zugriffssteuerung erforderliche Arbeit minimieren.

Passthrough-Authentifizierung

Für die Passthrough-Authentifizierung mit beliebiger Tokentransformation gibt es keine gleichwertige Microsoft-Technologie wie ACS. Wenn dies ihre Kunden benötigen, ist Auth0 möglicherweise der, der die nächstgelegene Annäherungslösung bereitstellt.

Fragen, Bedenken und Feedback

Wir wissen, dass viele Kunden der Zugriffssteuerung nach dem Lesen dieses Artikels keinen klaren Migrationspfad finden. Möglicherweise benötigen Sie Unterstützung oder Anleitungen bei der Bestimmung des richtigen Plans. Wenn Sie Ihre Migrationsszenarien und Fragen besprechen möchten, hinterlassen Sie bitte einen Kommentar auf dieser Seite.