Planen Sie Ihre SSO-Integration mit Microsoft Entra ID (ISVs)

Single Sign-On (SSO) mit Microsoft Entra ID erfordert Planung. Ihre frühen Entscheidungen wirken sich auf die Architektur, das Kunden-Onboarding und den langfristigen Upkeep Ihrer App aus. Dieser Leitfaden hilft unabhängigen Softwareanbietern (ISVs), diese Entscheidungen vor dem Erstellen zu treffen.

Die SSO-Planung für unabhängige Softwareanbieter (ISVs) unterscheidet sich von der Organisations-SSO. Als ISV entwerfen Sie Ihre App einmal und stellen sie anschließend in vielen Kundenmandanten bereit. Jeder Mandant kann unterschiedliche Anforderungen, Protokolle und Konfigurationen aufweisen.

Dieser Bereitstellungsansatz ist das Modell "Einmal entwerfen, pro Mandant konfigurieren". Die Entscheidungen, die Sie frühzeitig treffen, beeinflussen, wie gut Sie unterschiedliche Kunden unterstützen. Mangelhafte Planung führt zu Reibungsverlusten beim Onboarding, höherem Supportaufwand und entgangenen Enterprise-Verkäufen.

Um gut zu planen, verstehen Sie zuerst die Grundlagen. Hintergrundinformationen finden Sie unter What is Single Sign-On (SSO) und Grundlegendes zum SSO-Modell von Microsoft.

Verwenden Sie für die meisten modernen SaaS-ISVs die folgenden Standardwerte:

  • Multitenant-Architektur: Der Standardwert für skalierbare SaaS-Verteilung.
  • OpenID Connect (OIDC):Das empfohlene Protokoll für die neue Entwicklung.
  • Einzelseitenanwendungen (Single Page Applications, SPAs) und mobile Apps: Müssen OIDC verwenden.
  • SAML: Wählen Sie es nur für bestimmte Legacy-Enterprise-Kundenanforderungen aus.
  • Single-Tenant-Apps: scheitern bei der Validierung in der Microsoft Entra-App-Galerie.

Diese empfohlenen Standardwerte entsprechen modernen Entwicklungspraktiken und Microsoft Entra Validierungsanforderungen. Wenn Sie davon abweichen, ist während der Validierung häufig Nacharbeit erforderlich.

Important

Designentscheidungen wirken sich direkt darauf aus, ob Ihre App Microsoft Entra Validierung bestanden hat und eine Test-ID erhält. Ein falsches Mandantenmodell oder Protokoll führt häufig zu Nacharbeiten.

Verstehen Sie den ISV-SSO-Kontext in Microsoft Entra ID

Microsoft Entra ID verwendet ein strukturiertes Modell. Ihre App verfügt über eine globale Definition, die als Anwendungsobjekt bezeichnet wird und die App-Registrierung für alle Mandanten darstellt. In jedem Mandanten verfügt Ihre App zudem über eine mandantenspezifische Instanz, die als Dienstprinzipal bezeichnet wird. Wenn ein Kunde Ihre App zu seinem Mandanten hinzufügt, erstellt er deren Dienstprinzipal. Der Dienstprinzipal enthält die SSO-Konfiguration, die Benutzerzuweisungen und die Protokolleinstellungen dieses Mandanten.

Die Trennung zwischen anwendungsobjekt und Dienstprinzipalen ermöglicht es Ihrer App, unterschiedliche SSO-Protokolle und Konfigurationen über Mandanten hinweg zu unterstützen, während Ihr Kerndesign gleich bleibt. Jeder Mandant konfiguriert seine SSO-Einstellungen eigenständig, ohne dass sich dies auf andere Bereitstellungen auswirkt.

Kritische Auswirkung für ISVs: Die Protokollkonfiguration befindet sich im Dienstprinzipal. Daher muss Ihre App unterschiedliche SSO-Protokolle und Anspruchszuordnungen über Mandanten hinweg tolerieren. Ein Kunde kann SAML mit bestimmten Attributzuordnungen verwenden. Eine andere könnte OIDC mit unterschiedlichen Claims verwenden. Ihre App-Architektur muss diese Variante ordnungsgemäß behandeln.

Ausführliche Erläuterungen zu diesem Modell finden Sie unter Anwendungsobjekte und Dienstprinzipale undEinzelmandanten-Apps und mehrinstanzenfähige Apps.

Legen Sie Ihr Mandantenmodell fest

Für die meisten SaaS-ISVs ist die mehrinstanzenfähige Architektur die empfohlene Standardeinstellung. Sie können Ihre App als Einzelmandanten-App (eine Organisation) oder als Mehrmandanten-App (viele Organisationen) konzipieren. Diese Wahl wirkt sich stark auf Ihr SSO-Design, die Komplexität des Onboardings und die Skalierung Ihres Geschäftsmodells aus.

Mehrmandantenanwendungen (empfohlen) bedienen viele Kundenorganisationen über eine einzige App-Registrierung. Eine einzelne Registrierung vereinfacht die Bereitstellung und skaliert gut. Multitenant-Apps erfordern ein sorgfältiges Design für die Mandantenisolation und die Konfiguration pro Kunde.

Einzelmandantenanwendungen benötigen eine separate Bereitstellung pro Kunde. Sie geben eine stärkere Isolierung, fügen aber operative Arbeit hinzu. Wählen Sie diesen Ansatz nur für spezielle Unternehmens- oder Complianceanforderungen aus.

Auswirkungen auf Validierung und Veröffentlichung:

  • Einmandanten-Apps bestehen die Validierung für die Veröffentlichung im Microsoft Entra-Katalog nicht.
  • Mehrmandantenfähigkeit ist für eine skalierbare Distribution und die Aufnahme in den Katalog erforderlich.
  • Die Katalogveröffentlichung erfordert eine mehrinstanzenfähige Architektur, um vielfältige Kunden zu bedienen.

Die Wahl zwischen Einmandanten- und Mehrmandantenarchitektur lässt sich nur schwer ändern, sobald Kunden Ihre App nutzen. Ausführliche Anleitungen finden Sie unter Einmandanten- vs. Mehrmandanten-Apps.

Definieren der Anwendungsarchitektur und Anmeldemuster

Die Architektur Ihrer App bestimmt, welche Authentifizierungsflüsse und SSO-Muster Sie unterstützen können. Wählen Sie Ihre Architektur und Ihr Protokoll zusammen aus, und wählen Sie sorgfältig aus. Eine schlechte Abstimmung führt zu Nacharbeiten während der Validierung.

Empfohlene Architekturprotokollausrichtung:

  • Einzelseitenanwendungen (SPAs) → OIDC erforderlich (clientseitige Tokenverwaltung)
  • Mobile Anwendungen → OIDC erforderlich (systemeigene Authentifizierungsflüsse)
  • Moderne Webanwendungen → empfohlener OIDC-Standard (serverseitige Tokenbehandlung)
  • Legacy-Unternehmensanwendungen → SAML geeignet (XML-basierte Föderation)

Web-Apps können entweder SAML oder OpenID Connect verwenden, aber OIDC ist die empfohlene Standardeinstellung für die neue Entwicklung. Einzelseitenanwendungen und mobile Apps funktionieren am besten mit OIDC, da sie auf dem Client ausgeführt werden und moderne Authentifizierungsmuster verwenden.

Note

Wenn Sie falsch auswählen: Falsch ausgerichtete Architektur und Protokollauswahl erfordern häufig während der Überprüfung erhebliche Überarbeitungen und können die Veröffentlichung von Katalogen verzögern.

Ausführliche Anleitungen zu Anwendungstypen und Authentifizierungsmustern finden Sie unter Microsoft Identity Platform App-Typen und OAuth 2.0-Autorisierungscodefluss.

Überprüfen protokollspezifischer Planungsüberlegungen

ISVs müssen zwischen SAML 2.0 und OpenID Connect (OIDC) für SSO wählen. Für die meisten modernen SaaS ISVs ist OIDC der empfohlene Standardwert. Es entspricht modernen Entwicklungsmethoden, unterstützt moderne App-Architekturen und integriert einfacher.

Wählen Sie SAML nur für bestimmte Unternehmenskundenanforderungen oder ältere Integrationsanforderungen aus. SAML wird immer noch weit unterstützt und passt zu einigen Szenarien, aber in der Regel dauert es mehr Arbeit, um sie zu implementieren und zu konfigurieren.

Ihre Protokollauswahl wirkt sich direkt auf den Validierungserfolg und die Test-ID-Generierung aus. Apps, die empfohlene Muster und Protokolle verwenden, bestehen die Microsoft-Entra-Validierung in der Regel schneller. Nicht standardmäßige Auswahlmöglichkeiten benötigen möglicherweise zusätzliche Überprüfungszyklen.

Ein detailliertes Vergleichs- und Entscheidungsframework finden Sie unter SAML vs OpenID Connect: Auswählen des richtigen SSO-Protokolls.

Planung der Kundenkonfiguration und des Onboarding-Erlebnisses

Halten Sie die Konfiguration einfach, aber lassen Sie die kundenspezifischen Anpassungen zu. Einige Werte sind für jeden Kunden identisch, z. B. Umleitungs-URIs und Anwendungsbezeichner. Andere unterscheiden sich je Kunde, z. B. Anspruchszuordnung und Benutzerattribute.

Design für Automatisierung zuerst:

  • Automatisieren von Standardkonfigurationen nach Möglichkeit
  • Bereitstellen klarer Anleitungen für kundenspezifische Einstellungen
  • Planen, wie Kunden Konfigurationswerte abrufen und überprüfen
  • Testen des Onboardingprozesses mit mehreren Kundenszenarien

Schlechtes Onboarding-Design wirkt sich direkt auf die Kundenakzeptanz und den Supportaufwand aus. Konfigurationskonzepte finden Sie unter App-Registrierungskonzepte, SAML-Metadatendokumentation und Umleitungs-URI-Anleitungen.

Planen Sie Ansprüche, Identitätsdaten und die Autorisierungszuordnung

Definieren Sie die erforderlichen und optionalen Ansprüche frühzeitig. Einige Ansprüche, z. B. die Benutzer-ID, sind in der Regel erforderlich. Andere, z. B. Gruppenmitgliedschaften und benutzerdefinierte Attribute, können optional oder kundenspezifisch sein.

Berücksichtigen Sie die Variabilität von Kunden:

  • Verschiedene Kunden verfügen über unterschiedliche Identitätsdaten.
  • Anspruchsformate und Präferenzen für die Übermittlung variieren je nach Mandant
  • Testen Sie Ihre Anwendung mit Szenarien mit wenigen und vielen Ansprüchen
  • Dokumentfallbackverhalten für fehlende optionale Ansprüche

Informationen zu Anspruchs- und Tokenkonzepten finden Sie unter Token und Anspruchsübersicht, ID-Token und Sicherheitstoken.

Abmeldung, Lebenszyklus und langfristigen Betrieb planen

SSO geht über die erste Anmeldung hinaus. Planen Sie frühzeitig das Abmelden, die Sitzungsverwaltung und den Kontolebenszyklus. Diese Anforderungen treten im Vertrieb an Großunternehmen häufig als Kundenanforderungen auf.

Die wichtigsten Zu behandelnden Szenarien:

  • Einmaliges Abmelden über Anwendungen hinweg
  • Anpassung des Timeouts an die Richtlinien der Organisation
  • Kontoaktivierung und Bereinigung
  • Token-Aktualisierung und Ablaufverarbeitung

Implementierungsleitfaden finden Sie in der Dokumentation zu OpenID Connect-Abmelden und SAML-Anmeldereferenzen in der SAML-Protokolldokumentation.

Planen Sie von Anfang an für die Galerieanforderungen. Um sie im Microsoft Entra App-Katalog zu veröffentlichen, müssen Sie bestimmte Integrationsstandards erfüllen und Validierungstests bestehen, um eine Test-ID zu erhalten.

Validierungserfolgsfaktoren:

  • Multitenant-Architektur (erforderlich)
  • Protokollkonformität (OIDC zur schnelleren Validierung empfohlen)
  • Standardauthentifizierungsflüsse und Fehlerbehandlung
  • Ordnungsgemäße Anspruchs- und Tokenverwaltung

Apps, die etablierten Mustern folgen, werden in der Regel schneller überprüft. Schlechte Planungsentscheidungen werden häufig als Validierungsfehler angezeigt, die erhebliche Überarbeitungen erfordern.

Hinweise zur Veröffentlichung und zu den Validierungsanforderungen finden Sie in der Dokumentation zum Microsoft Entra-Anwendungskatalog.

Checkliste zur Bereitschaft für die SSO-Planung

Verwenden Sie die folgenden Tabellen, um zu bestätigen, dass Sie zur Überprüfung und Katalogveröffentlichung bereit sind. Jedes Element ist einer wichtigen SSO-Planungsentscheidung zugeordnet: Mandantenmodell, Anwendungsarchitektur, Protokollauswahl, Kundenkonfiguration, Ansprüche und Abmelden.

Prüfliste für den Anwendungsentwurf

Bestätigen Sie diese Auswahlmöglichkeiten für den Anwendungsentwurf vor der Überprüfung.

Bereitschaftselement Warum dies wichtig ist
Multitenant-Modell bestätigt Der Microsoft Entra App-Katalog akzeptiert nur mehrinstanzenfähige Anwendungen.
Definierte Anwendungsarchitektur (Web, SPA, Mobil oder API) Die Architektur bestimmt, welche Authentifizierungsflüsse gelten.
Authentifizierungsflüsse identifiziert und mit der Architektur abgestimmt Falsch ausgerichtete Flüsse verursachen Überprüfungsfehler.

Prüfliste für die Protokollauswahl

Bestätigen Sie Ihre Protokollauswahl und Ihre Auswirkungen.

Bereitschaftselement Warum dies wichtig ist
OIDC-Standard bestätigt oder geschäftlicher Grund für SAML dokumentiert OIDC ist der empfohlene Standardwert; Abweichungen müssen gerechtfertigt sein.
Die Protokollauswahl richtet sich an die Anwendungsarchitektur. SPAs und mobile Apps erfordern OIDC.
Protokollspezifische Auswirkungen, die für Ihren Anwendungstyp verstanden werden Verhindert späte Neugestaltungen während der Validierung.

Prüfliste für die Kundenerfahrung

Überprüfen Sie die Onboarding- und Konfigurationsoberfläche für Kunden.

Bereitschaftselement Warum dies wichtig ist
Konfigurationswerte, die als fix oder kundenspezifisch kategorisiert sind Bestimmt die Onboarding-Anweisungen und das Mandantenmodell.
Onboarding-Prozess zur Minimierung der Kundenkomplexität Geringere Reibungsverluste verbessern die Adaption durch die Mandantenadministratoren.
Anforderungen an Anspruchs- und Identitätsdaten definiert und getestet Verhindert Diskrepanzen bei der Laufzeit.

Prüfliste für Validierung und Veröffentlichung

Bestätigen Sie die Überprüfungs- und Veröffentlichungsbereitschaft.

Bereitschaftselement Warum dies wichtig ist
Anforderungen für die Veröffentlichung im Katalog werden bereits früh in der Entwicklung geprüft Vermeidet Nacharbeit vor der Einreichung.
Auswirkungen von berücksichtigten Designentscheidungen auf die Validierung Einige Entscheidungen blockieren die Überprüfung vollständig.
Geplanter Ansatz zur Abmeldung und Sitzungsverwaltung Erforderlich für Compliance und eine saubere Benutzeroberfläche.
Getestete Kontolebenszyklusszenarien Erfasst Randfälle bei der Deprovisionierung.

Prüfliste vor der Überprüfung

Schließen Sie diese letzte Überprüfung ab, bevor Sie mit der Überprüfung beginnen.

Bereitschaftselement Warum dies wichtig ist
Alle kritischen Entscheidungen dokumentiert und gerechtfertigt Beschleunigt die Übergabe an den Support und reduziert Nacharbeiten.
Test-ID-Validierungspfad bestätigt Erforderlich, bevor Sie den Veröffentlichungsprozess starten.
Nacharbeitsrisiko bewertet und minimiert Letzter Go-/No-Go-Entscheidungspunkt vor der Validierung.

Verwandte Inhalte

Verwenden Sie diese Ressourcen, um Ihre App zu registrieren, zu überprüfen und zu veröffentlichen.

Für ISV-Anwendungsentwickler:

Für IT-Administratoren:

  • Last updated on