Zuordnen von Anforderungen zu Mandanten in einer mehrinstanzenfähigen Lösung

Wenn eine Anforderung in Ihre Anwendung eingeht, müssen Sie den Mandantenkontext ermitteln, bei dem es sich um den Mandanten handelt, der die Anforderung vornimmt. Wenn Sie über mandantenspezifische Infrastruktur verfügen, die möglicherweise in verschiedenen geografischen Regionen gehostet wird, müssen Sie die eingehende Anforderung mit einem Mandanten abgleichen. Anschließend müssen Sie die Anforderung an die physische Infrastruktur weiterleiten, die die Ressourcen dieses Mandanten hosten soll, wie im folgenden Diagramm dargestellt:

Viele mehrinstanzenfähige Anwendungen verfügen auch über benutzerbasierte Berechtigungen. Die Mandantenzuordnung ist eine separate Aktivität. Sie müssen sowohl den Benutzer kennen, der die Anforderung stellt, als auch den Mandanten, in dem er arbeitet.

Dieser Artikel enthält Anleitungen für technische Entscheidungsträger zu den Ansätzen, die Sie berücksichtigen können, um Anfragen dem entsprechenden Mandanten zuzuordnen, und den damit verbundenen Abwägungen.

Ansätze zum Identifizieren von Mandanten

Es gibt mehrere Möglichkeiten, den Mandanten für eine eingehende Anfrage zu identifizieren. Jeder Ansatz erfordert eine Überprüfung eines Aspekts der eingehenden Anfrage.

Domänennamen

Wenn Sie mandantenspezifische Domänen- oder Unterdomänennamen verwenden, können Anforderungen wahrscheinlich mithilfe des Host-Headers, des X-Forwarded-Host-Headers oder eines anderen HTTP-Headers, der den ursprünglichen Hostnamen für jede Anforderung enthält, problemlos Mandanten zugeordnet werden.

Berücksichtigen Sie jedoch die folgenden Fragen:

• Woher sollen Benutzer wissen, welcher Domänenname für den Zugriff auf den Dienst verwendet werden soll?
• Haben Sie einen zentralen Einstiegspunkt, z. B. eine Startseite oder Anmeldeseite, die alle Mandanten verwenden? Wenn Sie dies tun, wie werden Benutzer den Mandanten auswählen, mit dem sie arbeiten?
• Welche anderen Informationen verwenden Sie, um den Zugriff auf die Ressourcen des Mandanten zu überprüfen, z. B. Autorisierungstoken? Enthalten die Autorisierungstoken die mandantenspezifischen Domänennamen?

HTTP-Anforderungseigenschaften

Wenn Sie keine mandantenspezifischen Domänennamen verwenden, können Sie möglicherweise dennoch Aspekte der HTTP-Anforderung verwenden, um den Mandanten zu identifizieren, für den eine bestimmte Anforderung gilt. Betrachten Sie beispielsweise eine HTTP-Anforderung, die den Mandantennamen als tailwindtraders identifiziert. Dies kann mit einem der folgenden Ansätze kommuniziert werden:

• Die URL-Pfadstruktur, z. B. https://app.contoso.com/tailwindtraders/.
• Eine Abfragezeichenfolge in der URL, wie z. B. https://contoso.com/app?tenant=tailwindtraders.
• Ein benutzerdefinierter HTTP-Anforderungsheader, z. B. Tenant-Id: tailwindtraders.

Wenn Sie diesen Ansatz verwenden, sollten Sie die folgenden Fragen berücksichtigen:

• Wissen Benutzer, wie sie auf den Dienst zugreifen können? Wenn Sie z. B. eine Abfragezeichenfolge zum Identifizieren von Mandanten verwenden, muss eine zentrale Zielseite die Benutzer auf die Seite des richtigen Mandanten weiterleiten, indem die Abfragezeichenfolge hinzugefügt wird?
• Verfügen Sie über einen zentralen Einstiegspunkt, etwa eine Landing Page oder eine Anmeldeseite, die von allen Mandanten verwendet wird? Wenn Sie dies tun, wie werden Benutzer den Mandanten auswählen, auf den sie zugreifen müssen?
• Stellt Ihre Anwendung APIs bereit? Ist Ihre Webanwendung beispielsweise eine Einzelseitenanwendung (Single Page Application, SPA) oder eine mobile Anwendung mit einem API-Back-End? Wenn dies der Fall ist, können Sie möglicherweise ein API-Gateway oder Reverse-Proxy verwenden, um die Mandantenzuordnung durchzuführen.

Tokenansprüche

Viele Anwendungen verwenden claimsbasierte Authentifizierungs- und Autorisierungsprotokolle wie OAuth 2.0 oder SAML. Diese Protokolle stellen autorisierungstoken für den Client bereit. Ein Token enthält eine Gruppe von Ansprüchen, bei denen es sich um Informationen zur Clientanwendung oder zum Benutzer handelt. Claims können verwendet werden, um Informationen wie die E-Mail-Adresse eines Benutzers zu kommunizieren. Ihr System kann dann die E-Mail-Adresse des Benutzers einschließen, die Zuordnung von Benutzer zu Mandant nachschlagen und dann die Anforderung an das entsprechende Deployment weiterleiten. Sie können auch die Mandantenzuordnung in Ihr Identitätssystem einschließen und dem Token einen Mandanten-ID-Claim hinzufügen.

Wenn Sie Claims zum Zuordnen von Anfragen zu Mandanten verwenden, sollten Sie die folgenden Fragen in Betracht ziehen:

• Verwenden Sie einen Anspruch, um einen Mandanten zu identifizieren? Welchen Anspruch verwenden Sie?
• Kann ein Benutzer Mitglied mehrerer Mandanten sein? Wenn dies möglich ist, wie werden Benutzer den Mandanten auswählen, mit dem sie für eine bestimmte Anforderung arbeiten möchten?
• Gibt es ein zentrales Authentifizierungs- und Autorisierungssystem für alle Mandanten? Wenn nicht, wie stellen Sie sicher, dass alle Token-Autoritäten konsistente Token und Claims ausstellen?

API-Schlüssel

Viele Anwendungen machen APIs verfügbar. Diese können für die interne Verwendung innerhalb Ihrer Organisation oder für die externe Verwendung durch Partner oder Kunden verwendet werden. Eine gängige Authentifizierungsmethode für APIs besteht darin, einen API-Schlüssel zu verwenden. API-Schlüssel werden für jede Anfrage bereitgestellt. Wenn Sie die Mandanten-ID aufzeichnen, für die ein Schlüssel ausgestellt wurde, können Sie die Mandanten-ID nachschlagen, wenn der Schlüssel verwendet wird.

API-Schlüssel können auf verschiedene Arten generiert werden. Hier sind zwei gängige Ansätze:

• Generieren Sie einen kryptografisch zufälligen Wert, und speichern Sie ihn zusammen mit der Mandanten-ID in einer Nachschlagetabelle. Wenn eine Anforderung empfangen wird, findet Ihr System den API-Schlüssel in der Nachschlagetabelle und ordnet ihn dann einer Mandanten-ID zu.
• Erstellen Sie eine aussagekräftige Zeichenfolge mit einer darin enthaltenen Mandanten-ID. Digital signieren Sie den Schlüssel mithilfe eines Ansatzes wie HMAC. Wenn Sie jede Anfrage verarbeiten, überprüfen Sie die Signatur und extrahieren dann die Mandanten-ID.

Berücksichtigen Sie die folgenden Fragen:

• Wie generieren und Sie API-Schlüssel und geben diese aus?
• Wie erhalten und speichern Ihre API-Clients den API-Schlüssel sicher?
• Müssen Ihre API-Schlüssel nach einem bestimmten Zeitraum ablaufen? Wie können Sie die API-Schlüssel Ihrer Clients rotieren, ohne Ausfallzeiten zu verursachen?
• Bieten vom Kunden generierte API-Schlüssel eine angemessene Sicherheitsstufe für Ihre APIs?

Clientzertifikate

Clientzertifikatauthentifizierung, manchmal auch als gegenseitiges TLS (mTLS) bezeichnet, wird häufig für die Dienst-zu-Dienst-Kommunikation und für unbeaufsichtigte Geräte oder Kioske verwendet, die von nicht authentifizierten Benutzern verwendet werden. Clientzertifikate bieten eine sichere Möglichkeit zum Authentifizieren von Clients. Ähnlich wie Token und Ansprüche stellen Clientzertifikate Attribute zur Verfügung, die zum Bestimmen des Mandanten verwendet werden können. Der Betreff des Zertifikats kann z. B. die E-Mail-Adresse des Benutzers enthalten, die zum Nachschlagen des Mandanten verwendet werden kann.

Berücksichtigen Sie bei der Planung der Verwendung von Clientzertifikaten für die Mandantenzuordnung die folgenden Faktoren:

• Wie können Sie die Von Ihrem Dienst vertrauenswürdigen Clientzertifikate sicher ausstellen und erneuern? Clientzertifikate können in der Handhabung komplex sein, da sie eine spezielle Infrastruktur zum Verwalten und Ausstellen von Zertifikaten benötigen. Bei unsachgemäßer Behandlung können diese Komplexitäten Ihre Sicherheit reduzieren , anstatt sie zu erhöhen.
• Werden Clientzertifikate nur für anfängliche Anmeldeanforderungen verwendet oder an alle Anforderungen an Ihren Dienst angefügt?
• Wird der Prozess der Ausstellung und Verwaltung von Zertifikaten unüberschaubar, wenn Sie über eine große Anzahl von Clients verfügen?
• Wie implementieren Sie die Zuordnung zwischen dem Clientzertifikat und dem Mandanten?

Umgekehrte Proxys

Ein Reverseproxy, auch als Anwendungsproxy bezeichnet, kann zum Weiterleiten von HTTP-Anforderungen verwendet werden. Ein Reverseproxy akzeptiert eine Anfrage von einem Ingress-Endpunkt und kann die Anfrage an einen der vielen Back-End-Endpunkte weiterleiten. Reverse-Proxys sind nützlich für mandantenfähige Anwendungen, da sie die Zuordnung anhand eines bestimmten Teils der Anfrageinformationen vornehmen können und damit Ihre Anwendungsinfrastruktur entlasten.

Viele Reverseproxys können die Eigenschaften einer Anforderung verwenden, um eine Entscheidung über das Mandantenrouting zu treffen. Sie können den Zieldomänennamen, den URL-Pfad, die Abfragezeichenfolge, HTTP-Header und sogar Claims innerhalb von Token oder Teilen des Request-Body überprüfen.

Die folgenden gängigen Reverseproxys werden in Azure verwendet:

• Azure Front Door ist ein globaler Lastenausgleichsdienst und eine Webanwendungsfirewall. Es verwendet das globale Edge-Netzwerk von Microsoft, um schnelle, sichere und hoch skalierbare Webanwendungen zu erstellen. Sie können Regelsätze verwenden, um Mandanten-IDs zu extrahieren und sie in einen anderen Teil der Anforderung einzufügen.
• Azure Application Gateway ist ein verwalteter Lastenausgleich für Webdatenverkehr, den Sie in derselben physischen Region wie Ihr Back-End-Dienst bereitstellen.
• Azure API Management ist für API-Datenverkehr optimiert. Azure API Management bietet ein umfassendes Richtlinienmodul , das eine große Flexibilität zum Extrahieren von Mandanteninformationen aus Anforderungen bietet.
• Kommerzielle und Open-Source-Technologien (die Sie selbst hosten) umfassen nginx, Traefik und HAProxy.

Anforderungsvalidierung

Es ist wichtig, dass Ihre Anwendung überprüft, ob alle Anfragen, die sie empfängt, für den Mandanten autorisiert sind. Wenn Ihre Anwendung beispielsweise einen benutzerdefinierten Domänennamen verwendet, um Anforderungen dem Mandanten zuzuordnen, muss Ihre Anwendung dennoch überprüfen, ob jede von der Anwendung empfangene Anforderung für diesen Mandanten autorisiert ist. Obwohl die Anforderung einen Domänennamen oder einen anderen Mandantenbezeichner enthält, bedeutet dies nicht, dass Sie automatisch Zugriff gewähren sollten. Wenn Sie OAuth 2.0 verwenden, führen Sie die Überprüfung durch Prüfen der Zielgruppen - und Bereichsansprüche durch.

Berücksichtigen Sie bei der Implementierung der Anforderungsüberprüfung die folgenden Faktoren:

• Wie autorisieren Sie alle Anforderungen für Ihre Anwendung? Sie müssen Anfragen autorisieren, unabhängig vom Ansatz, den Sie verwenden, um sie physischer Infrastruktur zuzuordnen.
• Verwenden Sie vertrauenswürdige, weit verbreitete und gut gepflegte Authentifizierungs- und Autorisierungsframeworks und Middleware, anstatt alle Validierungslogik selbst zu implementieren. Erstellen Sie beispielsweise keine Tokensignaturüberprüfungslogik oder Clientzertifikatkryptografiebibliotheken. Verwenden Sie stattdessen Features Ihrer Anwendungsplattform (oder bekannte vertrauenswürdige Pakete), die überprüft und getestet wurden.

Performance

Die Mandantenzuordnungslogik wird wahrscheinlich bei jeder Anfrage an Ihre Anwendung ausgeführt. Überlegen Sie, wie gut der Mandantenzuordnungsprozess skaliert wird, wenn Ihre Lösung wächst. Wenn Sie beispielsweise eine Datenbanktabelle als Teil Ihrer Mandantenzuordnung abfragen, unterstützt die Datenbank eine hohe Last? Wenn für Ihre Mandantenzuordnung eine Entschlüsselung eines Tokens erforderlich ist, werden die Berechnungsanforderungen im Laufe der Zeit zu hoch? Wenn Ihr Traffic relativ bescheiden ist, wirkt sich dies wahrscheinlich nicht auf die Gesamtleistung aus. Wenn Sie jedoch über eine anwendung mit hoher Skalierung verfügen, kann der Aufwand, der an dieser Zuordnung beteiligt ist, erheblich werden.

Sitzungscookies

Ein Ansatz zur Verringerung des Leistungsaufwands der Mandantenzuordnungslogik besteht darin, Sitzungscookies zu verwenden. Anstatt die Zuordnung für jede Anfrage durchzuführen, sollten Sie die Informationen nur für die erste Anfrage jeder Session berechnen. Ihre Anwendung stellt dann dem Client ein Sitzungscookie bereit. Der Client übergibt das Sitzungscookies an Ihren Dienst mit allen nachfolgenden Clientanforderungen innerhalb dieser Sitzung.

Berücksichtigen Sie die folgenden Fragen:

• Können Sie Sitzungscookies verwenden, um den Aufwand der Zuordnung von Anfragen an Mandanten zu verringern?
• Welche Dienste verwenden Sie, um Anfragen an die physischen Bereitstellungen für jeden Mandanten weiterzuleiten? Unterstützen diese Dienste Cookie-basierte Sitzungen?

Mandantenmigration

Mandanten müssen häufig im Rahmen des Mandantenlebenszyklus in eine neue Infrastruktur verschoben werden. Wenn ein Mandant in eine neue Bereitstellung verschoben wird, können sich die HTTP-Endpunkte, auf die er zugreift, ändern. Berücksichtigen Sie in diesem Fall, dass sich Ihr Mandantenzuordnungsprozess ändern muss. Möglicherweise müssen Sie die folgenden Faktoren berücksichtigen:

• Wenn Ihre Anwendung Domänennamen für Mapping-Anfragen verwendet, ist möglicherweise auch eine DNS-Änderung zum Zeitpunkt der Migration erforderlich. Je nach Gültigkeitsdauer (TTL) der DNS-Einträge in Ihrem DNS-Dienst kann es einige Zeit dauern, bis die DNS-Änderung an die Clients weitergegeben wird.
• Wenn Ihre Migration die Adressen von Endpunkten während des Migrationsprozesses ändert, sollten Sie Anforderungen für den Mandanten vorübergehend auf eine Wartungsseite umleiten, die automatisch neu geladen wird.

Contributors

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

• Daniel Scott-Raynsford | Partner Technology Strategist

Andere Mitwirkende:

• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Paolo Salvadori | Principal Customer Engineer, FastTrack für Azure
• Arsen Vladimirskiy | Hauptkundeningenieur, FastTrack für Azure

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

Nächster Schritt

Erfahren Sie mehr über die Identität in einer Mehrinstanzenanwendung.