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

Wenn eine Anforderung bei Ihrer Anwendung eintrifft, müssen Sie den Mandanten bestimmen, für den die Anforderung vorgesehen ist. Wenn Sie über mandantenspezifische Infrastruktur verfügen, die möglicherweise sogar in verschiedenen geografischen Regionen gehostet wird, müssen Sie die eingehende Anforderung einem Mandanten zuordnen. Anschließend müssen Sie die Anforderung wie unten gezeigt an die physische Infrastruktur weiterleiten, die die Ressourcen dieses Mandanten hostet:

Auf dieser Seite erhalten technische Entscheidungsträger Informationen zu den Ansätzen, die sie beim Zuordnen von Anforderungen zum entsprechenden Mandanten in Betracht ziehen können, sowie zu den Vor- und Nachteilen dieser Ansätze.

Ansätze zum Identifizieren von Mandanten

Es gibt mehrere Möglichkeiten, den Mandanten für eine eingehende Anforderung zu identifizieren.

Domänennamen

Wenn Sie mandantenspezifische Domänen- oder Unterdomänennamen verwenden, ist es wahrscheinlich, dass Anforderungen problemlos Mandanten zugeordnet werden können. Dazu können der Host-Header oder ein anderer HTTP-Header verwendet werden, der den ursprünglichen Hostnamen für jede Anforderung enthält.

Stellen Sie sich jedoch die folgenden Fragen:

• Woher wissen Benutzer, welcher Domänenname für den Zugriff auf den Dienst verwendet wird?
• Verfügen Sie über einen zentralen Einstiegspunkt, etwa eine Landing Page oder eine Anmeldeseite, die von allen Mandanten verwendet wird? Wenn dies der Fall ist, wie identifizieren Benutzer den Mandanten, auf den sie zugreifen müssen?
• Welche weiteren Informationen verwenden Sie, um den Zugriff auf den 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 wie folgt kommuniziert werden:

• Über die URL-Pfadstruktur, z. B https://app.contoso.com/tailwindtraders/.
• Über eine Abfragezeichenfolge in der URL, z. B. https://contoso.com/app?tenant=tailwindtraders.
• Über einen benutzerdefinierten HTTP-Anforderungsheader, z. B. Tenant-Id: tailwindtraders.

Bei Verwendung dieses Ansatzes sollten Sie die folgenden Fragen berücksichtigen:

• Wissen Benutzer, wie sie auf den Dienst zugreifen? Wenn Sie z. B. eine Abfragezeichenfolge verwenden, um Mandanten zu identifizieren, muss eine zentrale Landing Page Benutzer durch Hinzufügen der Abfragezeichenfolge an den richtigen Mandanten weiterleiten?
• Verfügen Sie über einen zentralen Einstiegspunkt, etwa eine Landing Page oder eine Anmeldeseite, die von allen Mandanten verwendet wird? Wenn dies der Fall ist, wie identifizieren Benutzer den Mandanten, auf den sie zugreifen müssen?
• Stellt Ihre Anwendung APIs zur Verfügung? Ist Ihre Webanwendung beispielsweise eine Single-Page-Anwendung (SPA) oder eine mobile Anwendung mit einem API-Back-End? Wenn dies der Fall ist, können Sie möglicherweise ein API-Gateway oder einen Reverseproxy verwenden, um die Mandantenzuordnung durchzuführen.

Tokenansprüche

Viele Anwendungen verwenden anspruchsbasierte Authentifizierungs- und Autorisierungsprotokolle wie OAuth 2.0 oder SAML. Diese Protokolle stellen Autorisierungstoken für den Client zur Verfügung. Ein Token enthält einen Satz von Ansprüchen, bei denen es sich um Informationen zur Clientanwendung oder zum Benutzer handelt. Ansprüche 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 einbinden, die Zuordnung zwischen Benutzer und Mandant ermitteln und die Anforderung dann an die entsprechende Bereitstellung weiterleiten. Sie können die Mandantenzuordnung sogar in Ihr Identitätssystem einbinden und dem Token einen Mandanten-ID-Anspruch hinzufügen.

Wenn Sie Ansprüche zum Zuordnen von Anforderungen zu Mandanten verwenden, sollten Sie die folgenden Fragen berücksichtigen:

• 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 wählen Benutzer dann die Mandanten aus, mit denen sie arbeiten möchten?
• Gibt es ein zentrales Authentifizierungs- und Autorisierungssystem für alle Mandanten? Wenn dies nicht der Fall ist, wie stellen Sie sicher, dass alle Tokenstellen konsistente Token und Ansprüche ausstellen?

API-Schlüssel

Viele Anwendungen stellen APIs bereit. Diese können für interne Verwendung in Ihrer Organisation oder für externe Verwendung durch Partner oder Kunden vorgesehen sein. Eine gängige Authentifizierungsmethode für APIs ist die Verwendung eines API-Schlüssels. API-Schlüssel werden bei jeder Anforderung bereitgestellt und können verwendet werden, um nach dem Mandanten zu suchen.

API-Schlüssel können auf verschiedene Weise generiert werden. Ein gängiger Ansatz ist das Generieren eines kryptografisch zufälligen Werts und das Speichern in einer Nachschlagetabelle zusammen mit der Mandanten-ID. Wenn eine Anforderung empfangen wird, findet Ihr System den API-Schlüssel in der Nachschlagetabelle und ordnet ihn dann einer Mandanten-ID zu. Ein weiterer Ansatz besteht darin, eine aussagekräftige Zeichenfolge mit einer darin enthaltenen Mandanten-ID zu erstellen. Anschließend würden Sie den Schlüssel digital signieren, indem Sie einen Ansatz wie HMAC verwenden. Wenn Sie jede Anforderung verarbeiten, überprüfen Sie die Signatur und extrahieren dann die Mandanten-ID.

Stellen Sie sich die folgenden Fragen:

• Wie generieren und Sie API-Schlüssel und geben diese aus?
• Wie empfangen und speichern Ihre API-Clients den API-Schlüssel sicher?
• Müssen Ihre API-Schlüssel nach einem bestimmten Zeitraum ablaufen? Wie rotieren Sie die API-Schlüssel Ihrer Clients, ohne Ausfallzeiten zu verursachen?
• Bietet die ausschließliche Nutzung von API-Schlüsseln, die von Kunden rotiert werden, ein angemessenes Maß an Sicherheit für Ihre APIs?

Clientzertifikate

Clientzertifikatauthentifizierung, manchmal auch als gegenseitiges TLS (mTLS) bezeichnet, wird häufig für die Kommunikation zwischen Diensten verwendet. 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. Beispielsweise kann der Betreff des Zertifikats 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 Folgendes:

• Wie können Sie die Clientzertifikate, die von Ihrem Dienst als vertrauenswürdig eingestuft werden, sicher ausstellen und erneuern? Das Arbeiten mit Clientzertifikaten kann komplex sein, da für die Verwaltung und Ausstellung von Zertifikaten eine spezielle Infrastruktur erforderlich ist.
• 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?

Reverseproxys

Ein Reverseproxy, der auch als Anwendungsproxy bezeichnet wird, kann zum Routen von HTTP-Anforderungen verwendet werden. Ein Reverseproxy akzeptiert eine Anforderung von einem Eingangsendpunkt und kann die Anforderung an einen von vielen Back-End-Endpunkten weiterleiten. Reverseproxys sind für mehrinstanzenfähige Anwendungen nützlich, da sie die Zuordnung zwischen einigen Anforderungsinformationen durchführen und Ihre Anwendungsinfrastruktur von dieser Aufgabe entlasten.

Viele Reverseproxys können die Eigenschaften einer Anforderung verwenden, um eine Entscheidung über das Mandantenrouting zu treffen. Sie können den Namen der Zieldomäne, den URL-Pfad, die Abfragezeichenfolge, HTTP-Header und sogar Ansprüche innerhalb von Token überprüfen.

Die folgenden gängigen Reverseproxys werden in Azure verwendet:

• Azure Front Door ist ein globaler Lastenausgleich und eine Web Application Firewall. Er verwendet das globale Microsoft Edge-Netzwerk, um schnelle, sichere und hochgradig skalierbare Webanwendungen zu erstellen.
• Azure Application Gateway ist ein verwalteter Lastenausgleich für Webdatenverkehr, den Sie in derselben physischen Region wie Ihren Back-End-Dienst bereitstellen.
• Azure API Management ist für API-Datenverkehr optimiert.
• 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 empfangenen Anforderungen für den Mandanten autorisiert sind. Wenn Ihre Anwendung beispielsweise einen benutzerdefinierten Domänennamen verwendet, um Anforderungen dem Mandanten zu zuordnen, muss Ihre Anwendung trotzdem ü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, indem Sie die Zielgruppen- und Bereichsansprüche untersuchen.

Beim Implementieren der Anforderungsvalidierung sollten Sie Folgendes berücksichtigen:

• Wie autorisieren Sie alle Anforderungen für Ihre Anwendung? Sie müssen Anforderungen autorisieren, unabhängig davon, welchen Ansatz Sie verwenden, um sie der physischen Infrastruktur zu zuordnen.
• Verwenden Sie vertrauenswürdige, weit verbreitete und gut gepflegte Authentifizierungs- und Autorisierungsframeworks und Middleware, anstatt die gesamte Validierungslogik selbst zu implementieren. Erstellen Sie beispielsweise keine Tokensignatur-Validierungslogik oder Kryptografiebibliotheken für Clientzertifikate. Verwenden Sie stattdessen Features Ihrer Anwendungsplattform (oder bekannte vertrauenswürdige Pakete), die überprüft und getestet wurden.

Leistung

Die Mandantenzuordnungslogik wird wahrscheinlich für jede Anforderung Ihrer Anwendung ausgeführt. Überlegen Sie, wie gut der Mandantenzuordnungsprozess skaliert werden kann, wenn Ihre Lösung wächst. Wenn Sie beispielsweise eine Datenbanktabelle im Rahmen Ihrer Mandantenzuordnung abfragen, unterstützt die Datenbank eine große Last? Wenn ihre Mandantenzuordnung die Entschlüsselung eines Tokens erfordert, werden die Berechnungsanforderungen im Laufe der Zeit zu hoch? Wenn der Datenverkehr relativ gering ist, wirkt sich dies wahrscheinlich nicht auf die Gesamtleistung aus. Wenn Sie jedoch über eine Anwendung mit großer Skalierung verwenden, kann der Mehraufwand für diese Zuordnung erheblich werden.

Sitzungsaffinität

Ein Ansatz zum Reduzieren des Leistungsmehraufwands der Mandantenzuordnungslogik ist die Verwendung von Sitzungsaffinität. Anstatt die Zuordnung für jede Anforderung durchzuführen, können Sie die Informationen nur bei der ersten Anforderung für jede Sitzung berechnen. Ihre Anwendung stellt dann ein Sitzungscookie für den Client bereit. Der Client übergibt das Sitzungscookie wieder an Ihren Dienst mit allen nachfolgenden Clientanforderungen innerhalb dieser Sitzung.

Stellen Sie sich die folgenden Fragen:

• Können Sie die Sitzungsaffinität verwenden, um den Mehraufwand für das Zuordnen von Anforderungen zu Mandanten zu reduzieren?
• Welche Dienste verwenden Sie, um Anforderungen an die physischen Bereitstellungen für jeden Mandanten weiterzuleiten? Unterstützen diese Dienste cookiebasierte Sitzungsaffinität?

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 ändern, auf die er zugreift. Beachten Sie, dass Ihr Mandantenzuordnungsprozess aktualisiert werden muss, wenn dies geschieht. Sie sollten Folgendes berücksichtigen:

• Wenn Ihre Anwendung Domänennamen für die Zuordnung von Anforderungen verwendet, ist zum Zeitpunkt der Migration möglicherweise auch eine DNS-Änderung erforderlich. Je nach Lebenszeit (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 an eine Wartungsseite umleiten, die automatisch aktualisiert wird.

Beitragende

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

Hauptautor:

• Daniel Scott-Raynsford | Partner Technology Strategist

Andere Mitwirkende:

• John Downs | Principal Software Engineer
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Erfahren Sie mehr über Überlegungen beim Arbeiten mit Domänennamen in einer mehrinstanzenfähigen Anwendung.