Freigeben über

Überlegungen zur Identitätsarchitektur in einer mehrinstanzenfähigen Lösung

  • Artikel

Die Identität ist ein wichtiger Aspekt von mehrinstanzenfähigen Lösungen. Die Identitätskomponenten Ihrer Anwendung sind für die folgenden beiden Aspekte verantwortlich:

  • Überprüfen, wer Benutzer*innen sind (Authentifizierung)
  • Erzwingen der Berechtigungen der Benutzer*innen im Bereich eines Mandanten (Autorisierung)

Ihre Kund*innen müssen möglicherweise auch externe Anwendungen autorisieren, um auf ihre Daten zuzugreifen oder in Ihre Lösung integrieren zu können. Die Identität von Benutzer*innen bestimmt, auf welche Informationen sie selbst oder ein Dienst zugreifen kann. Es ist wichtig, dass Sie Ihre Identitätsanforderungen berücksichtigen, um Ihre Anwendung und Ihre Daten zwischen Mandanten zu isolieren.

Achtung

Authentifizierungs- und Autorisierungsdienste innerhalb von mehrinstanzenfähigen Anwendungen und SaaS-Anwendungen werden in der Regel vom Identitätsanbieter (IdP) eines Drittanbieters bereitgestellt. Ein Identitätsanbieter ist meistens ein integraler Bestandteil einer IDaaS-Plattform (Identity-as-a-Service).

Das Erstellen eines eigenen IdP ist komplex und teuer. Zudem ist es schwierig, diesen sicher zu gestalten. Das Erstellen Ihres eigenen Identitätsanbieters ist ein Anti-Pattern. Wir raten davon ab.

Bevor Sie eine mehrinstanzenfähige Identitätsstrategie definieren, sollten Sie zunächst die allgemeinen Identitätsanforderungen Ihres Diensts berücksichtigen, einschließlich der folgenden Anforderungen:

  • Werden Benutzer*innen oder Workloadidentitäten verwendet, um auf eine einzelne Anwendung oder mehrere Anwendungen in einer Produktfamilie zuzugreifen? Beispielsweise kann eine Einzelhandelsproduktfamilie sowohl über eine Point-of-Sale-Anwendung als auch über eine Bestandsverwaltungsanwendung verfügen, die dieselbe Identitätslösung gemeinsam nutzen.
  • Planen Sie die Implementierung moderner Authentifizierungs- und Autorisierungsmethoden wie OAuth2 und OpenID Connect?
  • Stellt Ihre Lösung nur die Authentifizierungsmethode für Ihre benutzeroberflächenbasierten Anwendungen bereit? Oder bieten Sie auch API-Zugriff auf Ihre Mandanten und Drittanbieter?
  • Müssen Mandanten mit ihrem eigenen IdP verbunden werden, und müssen für jeden Mandanten mehrere unterschiedliche Identitätsanbieter unterstützt werden? Möglicherweise verfügen Sie über Mandanten mit Microsoft Entra ID, Auth0 und Active Directory-Verbunddiensten (AD FS), die alle mit Ihrer Lösung verknüpft werden sollen. Sie müssen auch verstehen, welche Verbundprotokolle der IdPs Ihrer Mandanten unterstützt werden, da die Protokolle die Anforderungen für Ihren eigenen IdP beeinflussen.
  • Gibt es spezifische Complianceanforderungen (z. B. die DSGVO), die sie erfüllen müssen?
  • Ist es erforderlich, dass die Identitätsinformationen Ihrer Mandanten in einer bestimmten geografischen Region vorliegen?
  • Benötigen Benutzer*innen, die Ihre Lösung verwenden, Zugriff auf Daten aus einem oder mehreren Mandanten innerhalb Ihrer Anwendung? Müssen Benutzer*innen die Möglichkeit haben, schnell zwischen Mandanten zu wechseln oder konsolidierte Informationen aus mehreren Mandanten anzuzeigen? Beispielsweise können Benutzer*innen, die sich beim Azure-Portal angemeldet haben, ganz einfach zwischen verschiedenen Microsoft Entra ID Directory-Instanzen und Abonnements wechseln, auf die sie Zugriff haben.

Wenn Sie Ihre allgemeinen Anforderungen festgelegt haben, können Sie mit der Planung genauerer Details und Anforderungen beginnen (z. B. Benutzerverzeichnisquellen und Registrierungs- bzw. Anmeldevorgänge).

Identitätsverzeichnis

Damit eine mehrinstanzenfähige Lösung Benutzer*innen oder einen Dienst authentifizieren und autorisieren kann, ist ein Ort zum Speichern von Identitätsinformationen erforderlich. Ein Verzeichnis kann autoritative Datensätze für jede Identität oder Verweise auf externe Identitäten enthalten, die im Verzeichnis eines anderen Identitätsanbieters gespeichert sind.

Wenn Sie ein Identitätssystem für Ihre mehrinstanzenfähige Lösung entwerfen, müssen Sie sich überlegen, welche der folgenden IdP-Typen Ihre Mandanten und Kund*innen benötigen:

  • Lokaler Identitätsanbieter: Ein lokaler Identitätsanbieter ermöglicht es Benutzer*innen, sich selbst beim Dienst anzumelden. Benutzer*innen geben einen Benutzernamen, eine E-Mail-Adresse oder einen Bezeichner (z. B. eine Kundenkartennummer) an. Sie stellen auch Anmeldeinformationen wie ein Kennwort bereit. Der IdP speichert sowohl den Benutzerbezeichner als auch die Anmeldeinformationen.
  • Soziales Netzwerk als Identitätsanbieter: Wenn ein soziales Netzwerk als Identitätsanbieter genutzt wird, können Benutzer*innen eine Identität verwenden, die sie in einem sozialen Netzwerk oder einem anderen öffentlichen Identitätsanbieter nutzen (z. B. Facebook, Google oder ein persönliches Microsoft-Konto).
  • Verwenden Sie das Microsoft Entra ID-Verzeichnis des Mandanten. Mandanten verfügen möglicherweise bereits über ein eigenes Microsoft Entra ID-Verzeichnis, und Ihre Lösung soll deren Verzeichnis als IdP für den Zugriff auf Ihre Lösung verwenden. Dieser Ansatz ist möglich, wenn Ihre Lösung als mehrinstanzenfähige Microsoft Entra ID-Anwendung erstellt wird.
  • Verbund mit dem Identitätsanbieter eines Mandanten: Mandanten haben möglicherweise eigene IdPs (andere als Microsoft Entra ID), und Ihre Lösung muss mit diesen verknüpft werden. Der Verbund ermöglicht Funktionen für das einmalige Anmelden (Single Sign-On, SSO), und Mandanten können den Lebenszyklus und die Sicherheitsrichtlinien der Benutzer*innen unabhängig von Ihrer Lösung verwalten.

Sie sollten berücksichtigen, ob Ihre Mandanten mehrere Identitätsanbieter unterstützen müssen. Möglicherweise müssen Sie beispielsweise lokale Identitäten, soziale Identitäten und Verbundidentitäten innerhalb eines einzelnen Mandanten unterstützen. Diese Anforderung ist üblich, wenn Unternehmen eine Lösung verwenden, die sowohl für die eigenen Mitarbeiter*innen als auch für Vertragspartner geeignet ist. Sie können eine Verbundmethode für den Zugriff ihrer eigenen Mitarbeiter*innen auf die Lösung verwenden und gleichzeitig Vertragspartnern oder Gastbenutzer*innen den Zugriff ermöglichen, die kein Konto im Verbund-IdP haben.

Speichern von Authentifizierungs- und Mandantenautorisierungsinformationen

Bei einer mehrinstanzenfähigen Lösung müssen Sie berücksichtigen, wo verschiedene Typen von Identitätsinformationen gespeichert werden sollen, einschließlich der folgenden:

  • Details zu Benutzer- und Dienstkonten, einschließlich ihrer Namen und anderer Informationen, die von Ihren Mandanten benötigt werden
  • Informationen, die erforderlich sind, um Ihre Benutzer*innen sicher zu authentifizieren, einschließlich Informationen, die zum Bereitstellen der Multi-Faktor-Authentifizierung (MFA) erforderlich sind.
  • Mandantenspezifische Informationen wie Mandantenrollen und Berechtigungen. Diese Informationen werden für die Autorisierung verwendet.

Achtung

Es wird nicht empfohlen, Authentifizierungsprozesse selbst zu erstellen. Moderne IdPs stellen diese Authentifizierungsdienste für Ihre Anwendung bereit, und sie enthalten auch andere wichtige Features wie die MFA und den bedingten Zugriff. Das Erstellen Ihres eigenen Identitätsanbieters ist ein Anti-Pattern. Wir raten davon ab.

Berücksichtigen Sie die folgenden Optionen zum Speichern von Identitätsinformationen:

  • Speichern Sie alle Identitäts- und Autorisierungsinformationen im IdP-Verzeichnis, und geben Sie sie für mehrere Mandanten frei.
  • Speichern Sie die Benutzeranmeldeinformationen im IdP-Verzeichnis und die Autorisierungsinformationen auf der Logikschicht zusammen mit den Mandanteninformationen.

Ermitteln der Anzahl der Identitäten für eine*n Benutzer*in

Es ist üblich, dass mehrinstanzenfähig Lösungen Benutzer*innen oder Workloadidentitäten den Zugriff auf die Anwendungen und Daten mehrerer Mandanten ermöglichen. Überlegen Sie, ob dieser Ansatz für Ihre Lösung erforderlich ist. Wenn dies der Fall ist, sollten Sie die folgenden Fragen berücksichtigen:

  • Sollten Sie eine einzelne Benutzeridentität für jede Person oder separate Identitäten für jede Mandantenbenutzerkombination erstellen?
    • Es wird empfohlen, eine einzelne Identität für jede Person zu verwenden (sofern möglich). Es wird schwierig, mehrere Benutzerkonten sowohl für Sie als Lösungsanbieter als auch für Ihre Benutzer*innen zu verwalten. Darüber hinaus sind viele der intelligenten Bedrohungsschutzmechanismen, die von einem modernen IdP angeboten werden, von jeder Person mit einem einzigen Benutzerkonto abhängig.
    • In einigen Situationen kann es jedoch erforderlich sein, dass Benutzer*innen über mehrere unterschiedliche Identitäten verfügen. Wenn Personen Ihr System beispielsweise sowohl für geschäftliche als auch für private Zwecke verwenden, müssen sie ihre Benutzerkonten trennen. Wenn für Ihre Mandanten strenge behördliche oder geografische Datenspeicheranforderungen gelten, kann es ebenso möglich sein, dass Personen über mehrere Identitäten verfügen müssen, damit sie die Vorschriften oder Gesetze einhalten können.
  • Wenn Sie mandantenbasierte Identitäten verwenden, sollten Sie das mehrfache Speichern von Anmeldeinformationen vermeiden. Benutzer*innen sollten ihre Anmeldeinformationen für eine einzelne Identität speichern, und Sie sollten Features wie Gastidentitäten verwenden, um auf dieselben Benutzeranmeldeinformationen aus den Identitätsdatensätzen mehrerer Mandanten zu verweisen.

Gewähren des Benutzerzugriffs auf Mandantendaten

Überlegen Sie, wie Benutzer*innen einem Mandanten zugeordnet werden. Beispielsweise können Sie während des Registrierungsvorgangs einen eindeutigen Einladungscode verwenden, den die Benutzer*innen beim ersten Zugriff auf einen Mandanten eingeben. In einigen Lösungen können Sie den Domänennamen der E-Mail-Adressen für die Registrierung der Benutzer*innen als Möglichkeit verwenden, den Mandanten zu identifizieren, dem sie angehören. Alternativ können Sie ein anderes Attribut des Identitätsdatensatzes der Benutzer*innen verwenden, um diese einem Mandanten zuzuordnen. Anschließend sollten Sie die Zuordnung basierend auf den zugrunde liegenden, unveränderlichen eindeutigen Bezeichnern für den Mandanten und die Benutzer*innen speichern.

Wenn Ihre Lösung so konzipiert ist, dass einzelne Benutzer*innen immer nur auf die Daten für einen einzelnen Mandanten zugreifen können, sollten Sie die folgenden Fragen berücksichtigen:

  • Wie erkennt der IdP, auf welchen Mandanten ein*e Benutzer*in zugreift?
  • Wie teilt der IdP der Anwendung den Mandantenbezeichner mit? Häufig wird dem Token ein Mandantenbezeichneranspruch hinzugefügt.

Wenn einzelnen Benutzer*innen Zugriff auf mehrere Mandanten gewährt werden muss, müssen Sie die folgenden Fragen berücksichtigen:

  • Wie identifiziert und erteilt Ihre Lösung Berechtigungen für Benutzer*innen, die Zugriff auf mehrere Mandanten haben? Kann ein*e Benutzer*in beispielsweise Administrator*in in einem Schulungsmandanten sein und schreibgeschützten Zugriff auf einen Produktionsmandanten haben? Oder können Sie separate Mandanten für unterschiedliche Abteilungen in einer Organisation verwenden, müssen dann aber mandantenübergreifend einheitliche Benutzeridentitäten verwalten?
  • Wie wechseln Benutzer*innen zwischen Mandanten?
  • Wie gibt eine Workloadidentität den Mandanten an, auf den sie zugreifen muss?
  • Sind mandantenspezifische Informationen im Identitätsdatensatz von Benutzer*innen gespeichert, die Informationen zwischen Mandanten preisgeben könnten? Angenommen, ein*e Benutzer*in hat sich mit einer Identität aus einem sozialen Netzwerk angemeldet und hat dann Zugriff auf zwei Mandanten erhalten. Mandant A hat die Benutzeridentität mit weiteren Informationen erweitert. Sollte Mandant B Zugriff auf die erweiterten Informationen haben?

Benutzerregistrierungsprozess für lokale Identitäten und Identitäten aus sozialen Netzwerken

Einige Mandanten müssen Benutzer*innen möglicherweise erlauben, sich für eine Identität in Ihrer Lösung zu registrieren. Die Self-Service-Registrierung ist möglicherweise erforderlich, wenn Sie keinen Verbund mit dem Identitätsanbieter eines Mandanten benötigen. Wenn ein Self-Service-Registrierungsprozess benötigt wird, sollten Sie die folgenden Fragen berücksichtigen:

  • Über welche Identitätsquellen dürfen sich Benutzer*innen registrieren? Kann ein*e Benutzer*in beispielsweise eine lokale Identität erstellen und ein soziales Netzwerk als Identitätsanbieter verwenden?
  • Werden nur bestimmte E-Mail-Domänen akzeptiert, wenn nur lokale Identitäten zulässig sind? Kann ein Mandant beispielsweise angeben, dass sich nur Benutzer*innen registrieren dürfen, die über eine @contoso.com-E-Mail-Adresse verfügen?
  • Was ist der Benutzerprinzipalname (UPN), der verwendet werden sollte, um jede lokale Identität während des Anmeldevorgangs eindeutig zu identifizieren? Beispielsweise sind E-Mail-Adressen, Benutzernamen, Telefonnummern und Kundenkartennummern allgemeine Optionen für UPNs. UPNs können sich jedoch im Laufe der Zeit ändern. Wenn Sie auf die Identität in den Autorisierungsregeln oder Überwachungsprotokollen Ihrer Anwendung verweisen, empfiehlt es sich, den zugrunde liegenden, unveränderlichen eindeutigen Bezeichner der Identität zu verwenden. Microsoft Entra ID stellt eine Objekt-ID (OID) bereit, die ein unveränderlicher Bezeichner ist.
  • Müssen Benutzer*innen ihren UPN überprüfen? Wie überprüfen Sie, ob die Informationen korrekt sind, wenn beispielsweise die E-Mail-Adresse oder Telefonnummer von Benutzer*innen als UPN verwendet wird?
  • Müssen Mandantenadministrator*innen Registrierungen genehmigen?
  • Benötigen Mandanten eine mandantenspezifische Registrierungsfunktion oder URL? Benötigen Ihre Mandanten beispielsweise eine Markenregistrierungsfunktion, wenn sich Benutzer*innen registrieren? Müssen Ihre Mandanten die Möglichkeit haben, eine Registrierungsanforderung abzufangen und zusätzliche Überprüfungsschritte durchzuführen, bevor die Anforderung weiter verarbeitet wird?

Mandantenzugriff für Benutzer*innen, die sich selbst registrieren

Wenn Benutzer*innen sich für eine Identität registrieren dürfen, muss es in der Regel einen Prozess geben, durch den sie Zugriff auf einen Mandanten erhalten. Der Registrierungsflow kann einen Zugriffsgewährungsprozess enthalten, der jedoch basierend auf den Informationen über die Benutzer*innen (z. B. ihren E-Mail-Adressen) auch automatisiert sein kann. Es ist wichtig, diesen Prozess zu planen und die folgenden Fragen zu berücksichtigen:

  • Wie bestimmt der Registrierungsflow, ob Benutzer*innen Zugriff auf einen bestimmten Mandanten gewährt werden soll?
  • Widerruft Ihre Lösung automatisch die Zugriffsberechtigungen, wenn Benutzer*innen keinen Zugriff mehr auf einen Mandanten haben sollen? Wenn Benutzer*innen beispielsweise eine Organisation verlassen, muss es einen manuellen oder automatisierten Prozess geben, mit dem ihr Zugriff aus dem Mandanten entfernt wird.
  • Müssen Sie Mandanten die Möglichkeit geben, die Benutzer*innen überwachen zu können, die Zugriff auf ihre Mandanten und Berechtigungen haben?

Automatisierte Kontolebenszyklusverwaltung

Eine allgemeine Anforderung für Unternehmenskunden einer Lösung sind Features, mit denen sie das Onboarding und das Offboarding von Konten automatisieren können. Offene Protokolle wie System for Cross-Domain Identity Management (SCIM) bieten einen branchenspezifischen Ansatz zur Automatisierung. Dieser automatisierte Prozess umfasst in der Regel nicht nur die Erstellung und Entfernung von Identitätsdatensätzen, sondern auch die Verwaltung von Mandantenberechtigungen. Beachten Sie die folgenden Fragen, wenn Sie die automatisierte Kontolebenszyklusverwaltung in einer mehrinstanzenfähigen Lösung implementieren:

  • Müssen Ihre Kund*innen pro Mandant einen automatisierten Lebenszyklusprozess konfigurieren und verwalten? Wenn beispielsweise das Onboarding für Benutzer*innen durchgeführt wurde, müssen Sie möglicherweise die Identität innerhalb mehrerer Mandanten in Ihrer Anwendung erstellen, wobei jeder Mandant über verschiedene Berechtigungen verfügt.
  • Müssen Sie SCIM implementieren? Oder können Sie stattdessen einen Mandantenverbund bereitstellen, um die „Source of Truth“ für Benutzer*innen unter der Kontrolle des Mandanten zu lassen, anstatt lokale Benutzer*innen zu verwalten?

Benutzerauthentifizierungsprozess

Wenn sich Benutzer*innen bei einer mehrinstanzenfähigen Anwendung anmelden, werden sie von Ihrem Identitätssystem authentifiziert. Sie sollten die folgenden Fragen berücksichtigen, wenn Sie Ihren Authentifizierungsprozess planen:

  • Müssen Ihre Mandanten ihre eigenen Richtlinien für die Multi-Faktor-Authentifizierung (MFA) konfigurieren? Wenn Ihre Mandanten beispielsweise aus der Finanzdienstleistungsbranche kommen, müssen sie strenge MFA-Richtlinien implementieren, während für kleine Onlinehändler nicht dieselben Anforderungen gelten.
  • Müssen Ihre Mandanten eigene Regeln für bedingten Zugriff konfigurieren? Beispielsweise müssen verschiedene Mandanten Anmeldeversuche aus bestimmten geografischen Regionen blockieren.
  • Müssen Ihre Mandanten den Anmeldevorgang für jeden Mandanten anpassen? Müssen Sie beispielsweise das Logo eines Kunden anzeigen? Oder müssen Informationen zu allen Benutzer*innen (z. B. Kundenkartennummern) aus einem anderen System extrahiert und an den Identitätsanbieter zurückgegeben werden, um sie dem Benutzerprofil hinzuzufügen?
  • Müssen Ihre Benutzer*innen zur Identität anderer Benutzer*innen wechseln? Ein Supportteammitglied muss beispielsweise die Probleme anderer Benutzer*innen untersuchen, indem er zu deren Benutzerkonto wechselt, ohne sich als diese Benutzer*innen authentifizieren zu müssen.
  • Müssen Ihre Benutzer*innen Zugriff auf die APIs für Ihre Lösung erhalten? Möglicherweise müssen Benutzer*innen oder Drittanbieteranwendungen beispielsweise Ihre APIs zur Erweiterung Ihrer Lösung ohne Benutzeroberfläche für einen Authentifizierungsflow direkt aufrufen.

Workloadidentitäten

Bei den meisten Lösungen stellen Identitäten häufig Benutzer*innen dar. Einige mehrinstanzenfähige Systeme ermöglichen Diensten und Anwendungen auch die Verwendung von Workloadidentitäten, um Zugriff auf Ihre Anwendungsressourcen zu erhalten. Möglicherweise müssen Ihre Mandanten auf eine API zugreifen, die von Ihrer Lösung bereitgestellt wird, damit sie einige ihrer Verwaltungsaufgaben automatisieren können.

Workloadidentitäten ähneln Benutzeridentitäten, erfordern in der Regel jedoch verschiedene Authentifizierungsmethoden wie Schlüssel oder Zertifikate. Workloadidentitäten verwenden keine Multi-Faktor-Authentifizierung. Stattdessen erfordern Workloadidentitäten in der Regel andere Sicherheitsmechanismen wie regelmäßige Schlüsselrotationen und den Ablauf von Zertifikaten.

Wenn Ihre Mandanten erwarten, dass sie den Workloadidentitätszugriff auf Ihre mehrinstanzenfähige Lösung aktivieren können, sollten Sie die folgenden Fragen berücksichtigen:

  • Wie werden Workloadidentitäten in jedem Mandanten erstellt und verwaltet?
  • Wie werden Workloadidentitätsanforderungen auf den Mandanten begrenzt?
  • Müssen Sie die Anzahl der Workloadidentitäten einschränken, die von jedem Mandanten erstellt werden?
  • Müssen Sie für jeden Mandanten Elemente für die bedingte Zugriffssteuerung für Workloadidentitäten bereitstellen? Beispielsweise muss ein Mandant eine Workloadidentität so einschränken, dass diese nicht von außerhalb einer bestimmten Region authentifiziert werden kann.
  • Welche Sicherheitsmechanismen stellen Sie Mandanten zur Verfügung, um sicherzustellen, dass Workloadidentitäten geschützt sind? Die automatisierte Schlüsselrotation, der Ablauf von Schlüsseln und Zertifikaten und die Anmeldungsrisikoüberwachung sind beispielsweise Methoden zur Verringerung des Risikos der missbräuchlichen Verwendung von Workloadidentitäten.

Verbund mit einem Identitätsanbieter für einmaliges Anmelden (SSO)

Mandanten, die bereits über eigene Benutzerverzeichnisse verfügen, erfordern möglicherweise, dass Ihre Lösung mit ihren Verzeichnissen verknüpft wird. Der Verbund ermöglicht es Ihrer Lösung, die Identitäten in ihrem Verzeichnis zu verwenden, anstatt ein anderes Verzeichnis mit unterschiedlichen Identitäten zu verwalten.

Der Verbund ist besonders wichtig, wenn einige Mandanten ihre eigenen Identitätsrichtlinien angeben möchten oder die Funktion für einmaliges Anmelden (Single Sign-On, SSO) aktivieren möchten.

Wenn Sie erwarten, dass Mandanten mit Ihrer Lösung verbunden sind, sollten Sie die folgenden Fragen berücksichtigen:

  • Wie lautet der Prozess zum Konfigurieren des Verbunds für einen Mandanten? Können Mandanten den Verbund selbst konfigurieren? Oder erfordert der Prozess eine manuelle Konfiguration und Wartung durch Ihr Team?
  • Welche Verbundprotokolle unterstützen Sie?
  • Welche Prozesse sind vorhanden, um sicherzustellen, dass der Verbund nicht falsch konfiguriert werden kann, um Zugriff auf einen anderen Mandanten zu gewähren?
  • Muss der Identitätsanbieter eines einzelnen Mandanten mit mehreren Mandanten in Ihrer Lösung verknüpft werden? Wenn Kund*innen beispielsweise über einen Schulungs- und Produktionsmandanten verfügen, müssen sie möglicherweise denselben Identitätsanbieter mit beiden Mandanten verknüpfen.

Autorisierungsmodelle

Entscheiden Sie sich für das Autorisierungsmodell, das für Ihre Lösung am sinnvollsten ist. Im Folgenden finden Sie zwei gängige Autorisierungsansätze:

  • Rollenbasierte Autorisierung: Benutzer*innen werden Rollen zugewiesen. Einige Features der Anwendung sind auf bestimmte Rollen beschränkt. Beispielsweise können Benutzer*innen in der Administratorrolle eine beliebige Aktion ausführen, während Benutzer*innen in einer niedrigeren Rolle möglicherweise über eine Teilmenge von Berechtigungen im gesamten System verfügen.
  • Ressourcenbasierte Autorisierung: Ihre Lösung bietet eine Reihe von unterschiedlichen Ressourcen, von denen jede über eine eigene Gruppe von Berechtigungen verfügt. Bestimmte Benutzer*innen können Administrator*innen einer Ressource sein und keinen Zugriff auf eine andere Ressource haben.

Diese Modelle unterscheiden sich voneinander, und der von Ihnen ausgewählte Ansatz wirkt sich auf Ihre Implementierung und die Komplexität der Autorisierungsrichtlinien aus, die Sie implementieren können.

Berechtigungen und Lizenzierung

In einigen Lösungen können Sie die Einzelbenutzerlizenzierung als Teil Ihres kommerziellen Preismodells verwenden. In diesem Fall stellen Sie verschiedene Ebenen von Benutzerlizenzen mit unterschiedlichen Funktionen bereit. Beispielsweise können Benutzer*innen mit einer Lizenz einen Teil der Features der Anwendung verwenden. Die Funktionen, auf die bestimmte Benutzer*innen basierend auf ihren Lizenzen zugreifen dürfen, werden manchmal als Berechtigung bezeichnet.

Obwohl das Nachverfolgen und Erzwingen von Berechtigungen den Vorgängen bei der Autorisierung ähnelt, werden diese Aspekte in der Regel vom Anwendungscode oder einem dedizierten Berechtigungssystem und nicht vom Identitätssystem verwaltet.

Identitätsskalierung und Authentifizierungsvolumen

Wenn mehrinstanzenfähige Lösungen erweitert werden, steigt die Anzahl der Benutzer*innen und Anmeldeanforderungen, die von der Lösung verarbeitet werden müssen. Sie sollten die folgenden Fragen berücksichtigen:

  • Wird das Benutzerverzeichnis auf die Anzahl der erforderlichen Benutzer*innen skaliert?
  • Verarbeitet der Authentifizierungsprozess die erwartete Anzahl von Anmeldungen und Registrierungen?
  • Gibt es Spitzen, die das Authentifizierungssystem nicht verarbeiten kann? Wenn sich beispielsweise alle im westlichen Teil der USA um 9:00 Uhr (PST) bei Ihrer Lösung anmelden, sorgt dies für eine Spitze hinsichtlich der Anmeldeanforderungen. Diese Situationen werden manchmal als Anmeldestürme bezeichnet.
  • Kann sich eine hohe Auslastung in anderen Teilen Ihrer Lösung auf die Leistung des Authentifizierungsprozesses auswirken? Verursacht eine hohe Anzahl von Authentifizierungsanforderungen Probleme für den Rest Ihrer Lösung, wenn Ihr Authentifizierungsprozess beispielsweise den Aufruf einer API auf Anwendungsebene erfordert?
  • Was geschieht, wenn Ihr IdP nicht verfügbar ist? Gibt es einen Notfallauthentifizierungsdienst, der die Geschäftskontinuität sicherstellt, während der IdP nicht verfügbar ist?

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Nächste Schritte

Lesen Sie den Artikel Architekturansätze für Identität in mehrinstanzenfähigen Lösungen.