Mapování požadavků na tenanty ve vícetenantových řešeních

Vždy, když do vaší aplikace přijde požadavek, musíte určit tenanta, pro který je požadavek určený. Pokud máte infrastrukturu specifickou pro tenanta, která může být dokonce hostovaná v různých geografických oblastech, musíte příchozí požadavek spárovat s tenantem. Pak je nutné požadavek předat fyzické infrastruktuře, která je hostitelem prostředků tohoto tenanta, jak je znázorněno níže:

Přístupy k identifikaci tenantů

Tenanta pro příchozí požadavek můžete identifikovat několika způsoby.

Názvy domén

Pokud používáte názvy domén nebo subdoménspecifických pro tenanta , je pravděpodobné, že požadavky lze snadno namapovat na tenanty. Zvažte však následující otázky:

• Jak budou uživatelé vědět, který název domény se má použít pro přístup ke službě?
• Máte centrální vstupní bod, jako je například vstupní stránka nebo přihlašovací stránka, který používají všichni tenanti? Pokud ano, jak uživatelé identifikují tenanta, ke který potřebují přístup?
• Jaké další informace používáte k ověření přístupu k tenantovi, například autorizační tokeny? Obsahují autorizační tokeny názvy domén specifické pro tenanta?

Vlastnosti požadavku HTTP

Pokud názvy domén specifické pro tenanta nebudete používat, stále můžete být schopni použít aspekty požadavku HTTP k identifikaci tenanta, pro který je konkrétní požadavek. Představte si například požadavek HTTP, který identifikuje název tenanta jako tailwindtraders . Můžete o tom komunikovat následujícím způsobem:

• Struktura cesty URL, například https://app.contoso.com/tailwindtraders/ .
• Řetězec dotazu v adrese URL, například https://contoso.com/app?tenant=tailwindtraders .
• Vlastní hlavička požadavku HTTP, například X-Tenant-Id: tailwindtraders .

Při použití tohoto přístupu byste měli zvážit následující otázky:

• Budou uživatelé vědět, jak k službě přistupovat? Pokud například k identifikaci tenantů použijete řetězec dotazu, bude muset centrální úvodní stránka směrovat uživatele na správného tenanta přidáním řetězce dotazu?
• Máte centrální vstupní bod, jako je například vstupní stránka nebo přihlašovací stránka, který používají všichni tenanti? Pokud ano, jak uživatelé identifikují tenanta, ke který potřebují přístup?
• Poskytuje vaše aplikace rozhraní API? Je například vaše webová aplikace jedno stránková aplikace (SPA) nebo mobilní aplikace s back-endem rozhraní API? Pokud je, můžete k mapování tenanta použít bránu rozhraní API nebo reverzní proxy server.

Deklarace identity tokenů

Mnoho aplikací používá ověřovací a autorizační protokoly založené na deklaracích, jako je OAuth 2.0 nebo SAML. Tyto protokoly poskytují klientovi autorizační tokeny. Token obsahuje sadu deklarací identity, což jsou části informací o klientské aplikaci nebo uživateli. Deklarace identity je možné použít ke sdělování informací, jako je e-mailová adresa uživatele. Váš systém pak může zahrnout e-mailovou adresu uživatele, hledat mapování mezi uživateli a tenantem a pak požadavek předat příslušné infrastruktuře fyzického tenanta. Nebo můžete dokonce zahrnout mapování tenanta do systému identit a přidat do tokenu deklaraci identity ID tenanta.

Pokud k mapování požadavků na tenanty používáte deklarace identity, měli byste zvážit následující otázky:

• Budete k identifikaci tenanta používat deklaraci identity? Kterou deklaraci identity použijete?
• Může být uživatel členem více tenantů? Pokud je to možné, jak si uživatelé vyberou tenanty, se které chtějí použít?
• Existuje centrální systém ověřování a autorizace pro všechny tenanty? Pokud ne, jak zajistíte, aby všechny autority tokenů vydávaly konzistentní tokeny a deklarace identity?

Klíče rozhraní API

Mnoho aplikací zveřejňuje rozhraní API. Ty můžou být pro interní použití ve vaší organizaci nebo pro externí použití partnery nebo zákazníky. Běžnou metodou ověřování rozhraní API je použití klíče rozhraní API. Klíče rozhraní API jsou k dispozici s každou žádostí a lze je použít k vyhledávání tenanta.

Klíče rozhraní API je možné vygenerovat několika způsoby. Běžným přístupem je vygenerovat kryptograficky náhodnou hodnotu a uložit ji do vyhledávací tabulky společně s ID tenanta. Po přijetí požadavku systém najde klíč rozhraní API ve vyhledávací tabulce a pak ho porovná s ID tenanta. Dalším přístupem je vytvořit smysluplný řetězec s ID tenanta, které je v ní obsažené, a pak digitálně podepsat klíč pomocí přístupu, jako je HMAC. Při zpracování každého požadavku ověříte podpis a pak extrahujte ID tenanta.

Zvažte následující otázky:

• Jak budete generovat a vydávat klíče rozhraní API?
• Jak budou klienti rozhraní API bezpečně přijímat a ukládat klíč rozhraní API?
• Potřebujete, aby platnost klíčů rozhraní API po určité době vypršela? Jak obměně klíčů rozhraní API vašich klientů, aniž by došlo k výpadku?
• Poskytuje jenom spoléhání na klíče rozhraní API zaregistrované zákazníkem odpovídající úroveň zabezpečení vašich rozhraní API?

Klientské certifikáty

Ověřování klientských certifikátů, někdy nazývané vzájemné TLS (mTLS), se běžně používá pro komunikaci mezi službou. Klientské certifikáty poskytují zabezpečený způsob ověřování klientů. Podobně jako tokeny a deklarace identity poskytují klientské certifikáty atributy, které lze použít k určení tenanta. Předmět certifikátu může například obsahovat e-mailovou adresu uživatele, kterou je možné použít k vyhledávání tenanta.

Při plánování použití klientských certifikátů pro mapování tenantů zvažte následující:

• Jak bezpečně vydáte a obnovíte klientské certifikáty, kterým vaše služba důvěřuje? Práce s klientskými certifikáty může být složitá, protože ke správě a vydávání certifikátů vyžadují speciální infrastrukturu.
• Budou se klientské certifikáty používat jenom pro počáteční žádosti o přihlášení nebo připojené ke všem požadavkům na vaši službu?
• Stane se proces vydávání a správy certifikátů nespravovatelným, když máte velký počet klientů?
• Jak budete implementovat mapování mezi klientským certifikátem a tenantem?

Reverzní proxy

Ke směrování požadavků HTTP je možné použít reverzní proxy server, označované také jako proxy aplikace. Reverzní proxy přijímá požadavek z koncového bodu příchozího přenosu dat a může ho předat jednomu z mnoha koncových bodů back-endu. Reverzní proxy jsou užitečné pro vícetenantové aplikace, protože mohou provádět mapování mezi informacemi o určité části požadavku a přetížit úlohu z infrastruktury aplikace.

Mnoho reverzních proxů může použít vlastnosti požadavku k rozhodnutí o směrování tenanta. Mohou zkontrolovat název cílové domény, cestu URL, řetězec dotazu, hlavičky PROTOKOLU HTTP a dokonce deklarace identity v rámci tokenů.

V Azure se používají následující běžné reverzní proxy:

• Azure Front Door je globální nástroj pro vyrovnávání zatížení a Firewall webových aplikací. Používá globální hraniční síť Microsoftu k vytváření rychlých, zabezpečených a vysoce škálovatelných webových aplikací.
• Azure Application Gateway je spravovaný nástroj pro vyrovnávání zatížení webového provozu, který nasazujete do stejné fyzické oblasti jako back-endová služba.
• Služba Azure API Management je optimalizovaná pro provoz rozhraní API.
• Mezi komerční a open source technologie (které hostíte sami) patří nginx, Traefik a HAProxy.

Ověření žádosti

Je důležité, aby vaše aplikace ověřila, že všechny požadavky, které obdrží, jsou pro tenanta autorizované. Pokud například vaše aplikace používá vlastní název domény k mapování požadavků na tenanta, musí aplikace stále kontrolovat, jestli jsou všechny požadavky přijaté aplikací pro tohoto tenanta autorizované. I když požadavek obsahuje název domény nebo jiný identifikátor tenanta, neznamená to, že byste měli přístup automaticky udělit. Při použití OAuth 2.0 provedete ověření tak, že prověříte cílovou skupinu a obor deklarací identity.

Při implementaci ověření požadavku byste měli zvážit následující:

• Jak autorizujete všechny požadavky na vaši aplikaci? Potřebujete autorizovat požadavky bez ohledu na přístup, který používáte k jejich mapování na fyzickou infrastrukturu.
• Místo implementace veškeré logiky ověřování sami používejte důvěryhodné a široce používané ověřovací a autorizační architektury a middleware. Například nevytvářete logiku ověřování podpisů tokenů ani knihovny kryptografie klientských certifikátů. Místo toho použijte funkce vaší aplikační platformy (nebo známých důvěryhodných balíčků), které byly ověřeny a otestovány.

Výkon

Logika mapování tenanta se pravděpodobně spouští při každém požadavku na vaši aplikaci. Zvažte, jak dobře se bude proces mapování tenanta škálovat s růstum vašeho řešení. Pokud například budete v rámci mapování tenanta dotazovat databázovou tabulku, bude databáze podporovat velké zatížení? Pokud mapování tenanta vyžaduje dešifrování tokenu, budou požadavky na výpočty v průběhu času příliš vysoké? Pokud je provoz poměrně mírné, pak to pravděpodobně nebude mít vliv na celkový výkon. Pokud ale máte aplikaci ve velkém měřítku, režie, která je součástí tohoto mapování, může být významná.

Spřažení relací

Jedním z přístupů ke snížení režie na výkon logiky mapování tenantů je použití spřažení relací. Místo mapování u každého požadavku zvažte výpočet informací pouze při prvním požadavku pro každou relaci. Vaše aplikace pak klientovi poskytne soubor cookie relace, který pak může předat zpět vaší službě se všemi následnými požadavky klientů v rámci této relace.

Zvažte následující otázky:

• Můžete pomocí spřažení relací snížit režijní náklady na mapování požadavků na tenanty?
• Jaké služby používáte ke směrování požadavků na fyzická nasazení pro každého tenanta? Podporují tyto služby spřažení relací na základě souborů cookie?

Migrace tenanta

Tenanty je často potřeba přesunout do nové infrastruktury v rámci životního cyklu tenanta. Když se tenant přesune do nového nasazení, koncové body HTTP, ke které přistupuje, se můžou změnit. Pokud k tomu dojde, zvažte, že je potřeba aktualizovat proces mapování tenanta. Možná budete muset vzít v úvahu následující:

• Pokud vaše aplikace používá názvy domén pro žádosti o mapování, může také vyžadovat změnu DNS v době migrace. Rozšíření změny DNS na klienty může chvíli trvat v závislosti na tom, kdy je záznam DNS ve vaší službě DNS aktivní.
• Pokud migrace změní adresy všech koncových bodů během procesu migrace, zvažte dočasné přesměrování žádostí o tenanta na stránku údržby, která se automaticky aktualizuje.

Další kroky

Přečtěte si informace o tom, co je třeba vzít v úvahu při práci s názvy domén ve vícetenantové aplikaci.