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

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

• Überprüfen der Identität eines Benutzers, die als Authentifizierung bezeichnet wird

• Die Durchsetzung der Berechtigungen eines Benutzers innerhalb eines Mandanten, bekannt als Autorisierung

Ihre Kunden möchten möglicherweise auch externe Anwendungen für den Zugriff auf ihre Daten autorisieren oder in Ihre Lösung integrieren. Die Identität eines Benutzers bestimmt, auf welche Informationen ein Benutzer oder Dienst zugreifen kann. Es ist wichtig, dass Sie Ihre Identitätsanforderungen berücksichtigen, um Ihre Anwendung und Daten zwischen Mandanten zu isolieren.

Bevor Sie eine Mehrinstanzenidentitätsstrategie definieren, sollten Sie zunächst die folgenden allgemeinen Identitätsanforderungen für Ihren Dienst berücksichtigen:

• Ermitteln Sie, ob Benutzer oder Workloadidentitäten auf eine einzelne Anwendung oder mehrere Anwendungen innerhalb einer Produktfamilie zugreifen. Einige Produktfamilien können unterschiedliche Anwendungen enthalten, die dieselbe Identitätsinfrastruktur nutzen, z. B. Point-of-Sale-Systeme und Bestandsverwaltungsplattformen.

• Überlegen Sie, ob Ihre Lösung moderne Authentifizierungs- und Autorisierungsstandards wie OAuth2 und OpenID Connect implementiert.

• Bewerten Sie, ob die Authentifizierung auf benutzeroberflächenbasierte Anwendungen beschränkt ist oder ob der API-Zugriff auch für Mandanten und Drittanbietersysteme gilt.

• Bestimmen Sie, ob Mandanten mit ihren eigenen IdPs verbunden und ob mehrere IdPs für jeden Mandanten unterstützt werden müssen. Sie können z. B. Mandanten mit Microsoft Entra-ID, Auth0 und Active Directory-Verbunddiensten haben, in denen jeder Mandant mit Ihrer Lösung verbunden ist. Ermitteln Sie, welche Partnerverbundprotokolle ihre IDPs verwenden, da diese Protokolle bestimmen, was Ihr IdP unterstützen muss.

• Überprüfen Sie alle anwendbaren Complianceanforderungen, die sie erfüllen müssen, z. B. die Datenschutz-Grundverordnung (DSGVO), die Ihre Identitätsstrategie gestalten.

• Ermitteln Sie, ob Mandanten Identitätsdaten in bestimmten geografischen Regionen speichern müssen, um rechtliche, Compliance- oder betriebliche Anforderungen zu erfüllen.

• Prüfen Sie, ob Benutzer auf Daten aus mehreren Mandanten innerhalb der Anwendung zugreifen. Wenn dies der Fall ist, müssen Sie möglicherweise einen nahtlosen Wechsel der Mandanten unterstützen oder konsolidierte Ansichten über Mandanten hinweg für bestimmte Benutzer bereitstellen. Benutzer, die sich beim Azure-Portal anmelden, können beispielsweise problemlos zwischen verschiedenen Microsoft Entra-ID-Verzeichnissen und Abonnements wechseln, auf die sie Zugriff haben.

Wenn Sie Ihre allgemeinen Anforderungen festlegen, können Sie mit der Planung spezifischerer Details und Anforderungen beginnen, z. B. Benutzerverzeichnisquellen und Anmelde- und Anmeldeabläufe.

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 autorisierende Datensätze für jede Identität enthalten. Oder es kann Verweise auf externe Identitäten enthalten, die im Verzeichnis eines anderen IdP 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 IdP: Mit einem lokalen IdP können sich Benutzer selbst für den Dienst registrieren. 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.

• Social IdP: Mit einem sozialen IdP können Benutzer eine Identität verwenden, die sie in einem sozialen Netzwerk oder einem anderen öffentlichen IdP haben, z. B. Facebook, Google oder ein persönliches Microsoft-Konto. Social IdPs werden häufig in SaaS-Lösungen (Business-to-Consumer, B2C) verwendet.

• Das Microsoft Entra-ID-Verzeichnis des Mandanten: In vielen SaaS-Lösungen (Business-to-Business, B2B) verfügen Mandanten möglicherweise bereits über ein eigenes Microsoft Entra ID-Verzeichnis, und sie möchten, dass Ihre Lösung ihr Verzeichnis als IdP für den Zugriff auf Ihre Lösung verwendet. Dieser Ansatz ist möglich, wenn Ihre Lösung als mehrinstanzenfähige Microsoft Entra-Anwendung erstellt wird.

• Verbindung mit dem IdP eines Mandanten: In einigen B2B-SaaS-Lösungen haben Mandanten möglicherweise ihren eigenen IdP, der nicht Microsoft Entra ID ist, und möchten, dass Ihre Lösung mit diesem föderiert wird. Verbund aktiviert einmaliges Anmelden (Single Sign-On, SSO). Außerdem können Mandanten den Lebenszyklus und die Sicherheitsrichtlinien ihrer Benutzer unabhängig von Ihrer Lösung verwalten.

Sie sollten überlegen, ob Ihre Mandanten mehrere IdPs unterstützen müssen. Beispielsweise muss ein einzelner Mandant lokale Identitäten, soziale Identitäten und Verbundidentitäten unterstützen. Diese Anforderung ist typisch, wenn Unternehmen eine Lösung verwenden, die sowohl für ihre Mitarbeiter als auch für Auftragnehmer vorgesehen ist. Sie können einen Partnerverbund verwenden, um Mitarbeitern Zugriff zu gewähren und gleichzeitig den Zugriff für Auftragnehmer oder Benutzer zu ermöglichen, die nicht über Konten im Verbund-IDP verfügen.

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 anderen Informationen, die Ihre Mandanten benötigen.

• Informationen, die erforderlich sind, um Ihre Benutzer sicher zu authentifizieren, einschließlich Informationen für die mehrstufige Authentifizierung (MFA).

• Mandantenspezifische Informationen, z. B. Mandantenrollen und Berechtigungen, zur Autorisierung.

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 Benutzeranmeldeinformationen im IdP-Verzeichnis. Speichern Von Autorisierungsdaten auf der Anwendungsebene zusammen mit Mandanteninformationen.

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

Multitenant-Lösungen ermöglichen häufig einem Benutzer oder einer Workloadidentität den Zugriff auf Anwendungsressourcen und -daten über mehrere Mandanten hinweg. Wenn dieser Ansatz erforderlich ist, berücksichtigen Sie die folgenden Faktoren:

• Entscheiden Sie, ob sie für jede Person eine einzelne Benutzeridentität erstellen oder separate Identitäten für jede Mandantenbenutzerkombination erstellen möchten.

  • Verwenden Sie nach Möglichkeit eine einzelne Identität für jede Person. Es vereinfacht die Kontoverwaltung sowohl für den Lösungsanbieter als auch für die Benutzer. Darüber hinaus verlassen sich viele der intelligenten Bedrohungsschutzfunktionen, die moderne IDPs bereitstellen, darauf, dass jede Person über ein einzelnes Benutzerkonto verfügt.

  • Verwenden Sie in einigen Szenarien mehrere unterschiedliche Identitäten. Wenn Personen Ihr System beispielsweise sowohl für geschäftliche als auch für private Zwecke verwenden, müssen sie ihre Benutzerkonten trennen. Oder wenn Ihre Mandanten strenge behördliche oder geografische Datenspeicheranforderungen haben, müssen sie möglicherweise, dass eine Person über mehrere Identitäten verfügt, um Vorschriften oder Gesetze einhalten zu können.

• Vermeiden Sie das mehrfache Speichern von Anmeldeinformationen, wenn Sie mandantenspezifische Identitäten verwenden. 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 Sie Benutzer einem Mandanten zuordnen möchten. Beispielsweise können Sie während des Registrierungsvorgangs einen eindeutigen Einladungscode bereitstellen, den Benutzer eingeben können, wenn sie zum ersten Mal auf einen Mandanten zugreifen. In einigen Lösungen kann der Domänenname der E-Mail-Adresse des Benutzers den zugehörigen Mandanten identifizieren. Alternativ können Sie ein anderes Attribut aus dem Identitätsdatensatz des Benutzers verwenden, um die Mandantenzuordnung zu ermitteln. Diese Zuordnung sollte dann basierend auf unveränderlichen, eindeutigen Bezeichnern sowohl für den Mandanten als auch für den Benutzer gespeichert werden.

Wenn Ihre Lösung jeden Benutzer auf den Zugriff auf Daten für einen einzelnen Mandanten beschränkt, sollten Sie die folgenden Entscheidungen treffen:

• Bestimmen Sie, wie der IdP erkennt, auf welchen Mandanten ein Benutzer zugreift.

• Erläutern, wie der IdP den Mandantenbezeichner an die Anwendung kommuniziert. Normalerweise wird dem Token ein Anspruch auf eine Mandanten-Kennung hinzugefügt.

Wenn einem einzelnen Benutzer der Zugriff auf mehrere Mandanten gewährt werden muss, sollten Sie die folgenden Entscheidungen treffen:

• Die Lösung muss Logik unterstützen, um Benutzer zu identifizieren und entsprechende Berechtigungen für alle Mandanten zu erteilen. Ein Benutzer verfügt beispielsweise über Administratorrechte in einem Mandanten, aber eingeschränkten Zugriff in einem anderen Mandanten. 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?

• Ein klarer Mechanismus sollte es Benutzern ermöglichen, zwischen Mandanten zu wechseln. Dieser Ansatz sorgt für eine reibungslose Benutzererfahrung und verhindert versehentlichen mandantenübergreifenden Zugriff.

• Workloadidentitäten müssen, wenn Sie sie verwenden, angeben, auf welche Mandanten sie zugreifen wollen. Diese Anforderung kann das Einbetten mandantenspezifischer Kontext in Authentifizierungsanforderungen umfassen.

• Überlegen Sie, ob instanzspezifische Informationen, die im Identitätsdatensatz eines Benutzers gespeichert sind, ungewollt zwischen den Mandanten durchsickern könnten. Wenn sich beispielsweise ein Benutzer mit einer sozialen Identität anmeldet und Zugriff auf zwei Mandanten erhält, und Mandant A erweitert das Benutzerprofil, bestimmen Sie, ob Mandant B Zugriff auf diese erweiterten Informationen haben soll.

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-Anmeldung kann erforderlich sein, wenn Sie keine Verbindung mit dem IdP eines Mandanten benötigen. Wenn ein Selbstanmeldungsprozess erforderlich ist, sollten Sie die folgenden Faktoren berücksichtigen:

• Definieren Sie, von welchen Identitätsquellen Benutzer sich registrieren dürfen. Ermitteln Sie beispielsweise, ob Benutzer eine lokale Identität erstellen und auch einen social IdP verwenden können.

• Geben Sie an, ob Ihre Lösung nur bestimmte E-Mail-Domänen zulässt, wenn lokale Identitäten verwendet werden. Ermitteln Sie beispielsweise, ob ein Mandant Die Registrierung auf Benutzer mit einer @contoso.com E-Mail-Adresse beschränken kann.

• Der Benutzerprinzipalname (USER Principal Name, UPN), der zum Identifizieren lokaler Identitäten verwendet wird, muss eindeutig festgelegt werden. Allgemeine UPNs umfassen E-Mail-Adressen, Benutzernamen, Telefonnummern oder Mitgliedschafts-IDs. Da UPNs sich ändern können, empfiehlt es sich, auf den zugrunde liegenden unveränderlichen eindeutigen Bezeichner für Autorisierung und Überwachung zu verweisen. Ein Beispiel ist die Objekt-ID (OID) in Microsoft Entra ID.

• Die Überprüfung von UPNs ist möglicherweise erforderlich, um ihre Genauigkeit sicherzustellen. Dieser Vorgang kann die Überprüfung des Besitzes einer E-Mail-Adresse oder Telefonnummer umfassen, bevor der Zugriff gewährt wird.

• Bei einigen Lösungen ist es u. U. erforderlich, dass Mandantenadministratoren Benutzeranmeldungen genehmigen. Dieser Genehmigungsprozess ermöglicht die administrative Kontrolle darüber, wer einem Mandanten beitritt.

• Entscheiden Sie, ob Mandanten ein mandantenspezifisches Registrierungserlebnis oder eine URL benötigen. Ermitteln Sie z. B., ob Ihre Mandanten beim Registrieren der Benutzer eine maßgeschneiderte Anmeldeerfahrung benötigen oder ob Sie die Möglichkeit haben, eine Registrierungsanforderung abzufangen und eine zusätzliche Überprüfung durchzuführen, bevor sie fortgesetzt wird.

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

Wenn sich Benutzer selbst für eine Identität registrieren können, definieren Sie einen Prozess, um ihnen Zugriff auf einen Mandanten zu gewähren. Der Registrierungsablauf kann einen manuellen Zugriffserteilungsprozess oder einen automatisierten Prozess basierend auf den Informationen zu den Benutzern, z. B. deren E-Mail-Adressen, umfassen. Es ist wichtig, diesen Prozess zu planen und die folgenden Faktoren zu berücksichtigen:

• Definieren Sie, wie der Registrierungsablauf bestimmt, dass einem Benutzer Zugriff auf einen bestimmten Mandanten gewährt wird.

• Definieren Sie, ob ihre Lösung den Benutzerzugriff auf einen Mandanten bei Bedarf automatisch widerruft. Wenn Benutzer beispielsweise eine Organisation verlassen, sollte ein manueller oder automatisierter Prozess vorhanden sein, um den Zugriff zu entfernen.

• Stellen Sie eine Benutzerüberwachungsfunktion bereit, damit Mandanten überprüfen können, welche Benutzer Zugriff auf ihre Umgebung haben und ihre zugewiesenen Berechtigungen verstehen können.

Automatisiertes Kontolebenszyklus-Management

Eine häufige Anforderung für Unternehmens- oder Unternehmenskunden einer Lösung ist eine Reihe von Features, mit denen sie das Onboarding und Offboarding von Konten automatisieren können. Offene Protokolle, z. B. System für domänenübergreifendes Identitätsmanagement (SCIM), bieten einen Branchenstandardansatz für die Automatisierung. Dieser automatisierte Prozess umfasst in der Regel das Erstellen und Entfernen von Identitätsdatensätzen und die Verwaltung von Mandantenberechtigungen. Berücksichtigen Sie die folgenden Faktoren, wenn Sie die automatisierte Kontolebenszyklusverwaltung in einer multiinstanzenübergreifenden Lösung implementieren:

• Ermitteln Sie, ob Ihre Kunden einen automatisierten Lebenszyklusprozess für jeden Mandanten konfigurieren und verwalten müssen. 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.

• Bestimmen Sie, ob Sie SCIM implementieren oder eine Verbindung anbieten müssen. Mit einer Verbindung behalten die Mandanten die Kontrolle über die Benutzerverwaltung, indem sie die zugrundeliegenden Daten in ihren eigenen Systemen behalten, anstatt lokale Benutzer in Ihrer Lösung zu verwalten.

Benutzerauthentifizierungsprozess

Wenn sich Benutzer*innen bei einer mehrinstanzenfähigen Anwendung anmelden, werden sie von Ihrem Identitätssystem authentifiziert. Berücksichtigen Sie beim Planen des Authentifizierungsprozesses die folgenden Faktoren:

• Einige Mandanten erfordern möglicherweise die Möglichkeit, ihre eigenen MFA-Richtlinien zu 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.

• Die Option zum Definieren benutzerdefinierter Regeln für bedingten Zugriff kann für Mandanten wichtig sein. Beispielsweise müssen verschiedene Mandanten Anmeldeversuche aus bestimmten geografischen Regionen blockieren.

• Bestimmen Sie, ob Mandanten den Anmeldevorgang einzeln anpassen müssen. Ihre Lösung muss z. B. das Logo eines Kunden anzeigen. Oder es muss möglicherweise Benutzerinformationen, z. B. eine Prämiennummer, aus einem anderen System abrufen und an den IdP zurückgeben, um das Benutzerprofil zu erweitern.

• Einige Benutzer müssen möglicherweise andere Benutzer imitieren. Ein Supportteammitglied möchte beispielsweise ein Problem untersuchen, das ein anderer Benutzer hat, indem er sein Benutzerkonto imitiert, ohne sich als Benutzer authentifizieren zu müssen.

• Der API-Zugriff ist für einige Benutzer oder externe Anwendungen möglicherweise erforderlich. Diese Szenarien können das direkte Aufrufen der APIs der Lösung umfassen, wodurch Standardbenutzerauthentifizierungsflüsse umgangen werden.

Workloadidentitäten

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

Microsoft Entra unterstützt Arbeitsauslastungsidentitäten, und andere IdPs unterstützen diese ebenfalls häufig.

Workloadidentitäten ähneln Benutzeridentitäten, erfordern in der Regel jedoch verschiedene Authentifizierungsmethoden wie Schlüssel oder Zertifikate. Workload-Identitä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 Instanzen den Workload-Identitätszugriff auf Ihre instanzenfähige Lösung ermöglichen können, sollten Sie die folgenden Faktoren berücksichtigen:

• Bestimmen Sie, wie Workloadidentitäten in jedem Mandanten erstellt und verwaltet werden.

• Entscheiden Sie, wie Workload-Identitätsanforderungen auf die Mandanten verteilt werden.

• Bewerten Sie, ob Sie die Anzahl der Workloadidentitäten einschränken müssen, die von jedem Mandanten erstellt werden.

• Ermitteln Sie, ob in jedem Mandanten für Workload-Identitäten bedingte Zugriffssteuerungen erforderlich sind. Beispielsweise muss ein Mandant eine Workloadidentität so einschränken, dass diese nicht von außerhalb einer bestimmten Region authentifiziert werden kann.

• Ermitteln Sie, welche Sicherheitskontrollen Sie den Mandanten zur Verfügung stellen, um die Sicherheit der Workloadidentitäten zu gewährleisten. So tragen beispielsweise die automatische Schlüsselerneuerung, der Ablauf von Schlüsseln und Zertifikaten sowie die Überwachung des Anmeldungsrisikos dazu bei, das Risiko eines Missbrauchs der Workloadidentität zu verringern.

Verbinden mit einem IdP für SSO

Mandanten, die bereits über eigene Benutzerverzeichnisse verfügen, möchten möglicherweise, dass Ihre Lösung mit ihren Verzeichnissen verbunden ist. Der Verbund ermöglicht es Ihrer Lösung, die Identitäten in ihrem Verzeichnis zu verwenden, anstatt ein separates Verzeichnis mit eigenen Identitäten zu verwalten.

Die Verbindung ist besonders wichtig, wenn einige Mandanten ihre eigenen Identitätsrichtlinien festlegen oder SSO-Erfahrungen ermöglichen möchten.

Wenn Sie erwarten, dass Mandanten mit Ihrer Lösung föderieren, sollten Sie die folgenden Faktoren berücksichtigen:

• Berücksichtigen Sie den Prozess zum Konfigurieren des Verbunds für einen Mandanten. Ermitteln Sie, ob Mandanten den Partnerverbund selbst konfigurieren oder ob der Prozess manuelle Konfiguration und Wartung durch Ihr Team erfordert.

• Definieren Sie, welche Verbundprotokolle Ihre Lösung unterstützt.

• Richten Sie Prozesse ein, die verhindern, dass Fehlkonfigurationen der Verbindung unbeabsichtigten Mandanten Zugang gewähren.

• Planen Sie, ob der IDP eines einzelnen Mandanten mit mehreren Mandanten in Ihrer Lösung verbunden werden muss. Wenn Kunden beispielsweise sowohl einen Trainings- als auch einen Produktions-Mandanten haben, müssen sie möglicherweise denselben IdP mit jedem Mandanten verbinden.

Autorisierungsmodelle

Entscheiden Sie sich für das Autorisierungsmodell, das für Ihre Lösung am sinnvollsten ist. Berücksichtigen Sie die folgenden gängigen Autorisierungsansätze:

• Rollenbasierte Autorisierung: Benutzern 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 jeder über einen eigenen Satz von Berechtigungen verfügt. Bestimmte Benutzer*innen können Administrator*innen einer Ressource sein und keinen Zugriff auf eine andere Ressource haben.

Diese Modelle sind unterschiedlich, 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 Szenario stellen Sie unterschiedliche Ebenen von Benutzerlizenzen bereit, die über unterschiedliche Funktionen verfügen. 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.

Es wird empfohlen, Berechtigungen in Ihrem Anwendungscode oder einem dedizierten Berechtigungssystem nachzuverfolgen und zu erzwingen, anstatt sich auf das Identitätssystem zu verlassen. Dieser Prozess ähnelt der Autorisierung, tritt jedoch außerhalb der Identitätsverwaltungsebene auf.

Es gibt mehrere Gründe für diese Trennung:

• Komplexität von Lizenzierungsmodellen: Lizenzierungsregeln sind häufig komplex und spezifisch für das Geschäftsmodell. Lizenzen können beispielsweise pro Arbeitsplatz, zeitbasiert (tägliche oder monatliche Zuordnung) sein, die gleichzeitige Verwendung beschränken oder bestimmte Regeln zur Neuzuweisung haben. Identitätsanbieter sind in der Regel für die Benutzerauthentifizierung und die Standardautorisierung konzipiert, nicht für komplexe kommerzielle Lizenzierungslogik.

• Unabhängigkeit: Wenn Sie sich auf Funktionen eines Identitätsanbieters für die Lizenzverwaltung verlassen, kann Ihre Lösung an diesen Anbieter oder dessen Einschränkungen gebunden werden. Wenn Sie Kunden unterstützen, die unterschiedliche Identitätsanbieter verwenden, müssen Sie trotzdem eine benutzerdefinierte Lösung erstellen.

Ein gängiges Muster besteht darin, Lizenzen innerhalb der Datenbank der Anwendung oder eines dedizierten Diensts zu verwalten. Wenn sich ein Benutzer anmeldet, ruft der Identitätsanbieter seine Berechtigungen ab und fügt sie als benutzerdefinierte Ansprüche in das Autorisierungstoken ein, die von den Anwendungskomponenten zur Laufzeit überprüft werden können.

Identitätsskalierung und Authentifizierungsvolumen

Wenn mehrinstanzenfähige Lösungen wachsen, erhöht sich die Anzahl der Benutzer und Anmeldeanforderungen, die die Lösung verarbeiten muss. Bewerten Sie diese Skalierbarkeitsaspekte:

• Bewerten Sie, ob das Benutzerverzeichnis skaliert wird, um die erforderliche Anzahl von Benutzern zu unterstützen.

• Bewerten Sie, ob der Authentifizierungsprozess die erwartete Anzahl von Anmeldungen und Registrierungen verarbeitet.

• Stellen Sie fest, ob es Spitzen gibt, die das Authentifizierungssystem nicht bewältigen kann. Zum Beispiel kann um 9 Uhr morgens pazifischer Zeit jeder in den westlichen USA mit der Arbeit beginnen und sich bei Ihrer Lösung anmelden, was zu einem Anstieg der Anmeldeanfragen führt. Diese Szenarien werden manchmal als Anmeldestürme bezeichnet.

• Ermitteln Sie, ob sich die hohe Last in Teilen Ihrer Lösung auf die Leistung des Authentifizierungsprozesses auswirkt. Wenn die Authentifizierung z. B. das Aufrufen einer Api auf Anwendungsebene erfordert, kann sich ein Anstieg der Authentifizierungsanforderungen auf die Gesamtleistung des Systems auswirken.

• Definieren Sie, wie sich Ihre Lösung verhält, wenn der IdP nicht verfügbar ist. Überlegen Sie, ob ein Sicherungsauthentifizierungsdienst eingeschlossen werden soll, um die Geschäftskontinuität aufrechtzuerhalten.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack für Azure

Andere Mitwirkende:

• Jelle Druyts | Principal Customer Engineer, FastTrack für Azure
• Landon Pierce | Senior Customer Engineer
• Sander van den Hoven | Senior Partner Technology Strategist
• Nick Ward | Senior Cloud Solution Architect

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Zugehörige Ressource

• Architekturansätze für Identität in mehrinstanzenfähigen Lösungen