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

Pokaždé, když do vaší aplikace přijde požadavek, musíte určit tenanta, pro kterého je žádost určená. Pokud máte infrastrukturu specifickou pro tenanta, která se může hostovat i v různých geografických oblastech, musíte shodovat příchozí požadavek s tenantem. Pak musíte požadavek předat fyzické infrastruktuře, která hostuje prostředky daného tenanta, jak je znázorněno níže:

Na této stránce poskytujeme pokyny pro pracovníky technického rozhodování o přístupech, které můžete zvážit při mapování žádostí na příslušného tenanta, a kompromisů, které se týkají přístupů.

Přístupy k identifikaci tenantů

Existuje několik způsobů, jak identifikovat tenanta pro příchozí požadavek.

Názvy domén

Pokud používáte názvy domén nebo subdomén specifických pro tenanty, je pravděpodobné, že požadavky se dají snadno namapovat na tenanty pomocí Host hlavičky nebo jiné hlavičky HTTP, která obsahuje původní název hostitele pro každý požadavek.

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

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

Vlastnosti požadavku HTTP

Pokud nepoužíváte názvy domén specifických pro tenanta, možná budete moct použít aspekty požadavku HTTP k identifikaci tenanta, pro kterého se konkrétní požadavek týká. Představte si například požadavek HTTP, který identifikuje název tenanta jako tailwindtraders. To se může sdělit pomocí následujícího:

• 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 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 získat přístup ke službě? Pokud například k identifikaci tenantů použijete řetězec dotazu, bude centrální cílová stránka muset uživatele nasměrovat na správného tenanta přidáním řetězce dotazu?
• Máte centrální vstupní bod, například cílovou stránku nebo přihlašovací stránku, kterou používají všichni tenanti? Pokud ano, jak uživatelé identifikují tenanta, ke kterému potřebují přístup?
• Poskytuje vaše aplikace rozhraní API? Jedná se například o jednostránkovou aplikaci (SPA) nebo mobilní aplikaci s back-endem rozhraní API? Pokud ano, 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, které jsou informacemi o klientské aplikaci nebo uživateli. Deklarace identity se dají použít ke komunikaci informací, jako je e-mailová adresa uživatele. Váš systém pak může obsahovat e-mailovou adresu uživatele, vyhledat mapování uživatele na tenanta a pak žádost předat příslušnému nasazení. Nebo můžete do systému identit zahrnout mapování tenanta a přidat do tokenu deklaraci IDENTITY ID tenanta.

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

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

Klíče rozhraní API

Mnoho aplikací zveřejňuje rozhraní API. Můžou se jednat o interní použití v rámci vaší organizace nebo pro externí použití partnery nebo zákazníky. Běžnou metodou ověřování pro rozhraní API je použití klíče rozhraní API. Klíče rozhraní API jsou k dispozici s jednotlivými žádostmi a dají se použít k vyhledá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 spolu s ID tenanta. Když se žádost obdrží, váš systém najde klíč rozhraní API ve vyhledávací tabulce a pak se shoduje s ID tenanta. Dalším přístupem je vytvoření smysluplného řetězce s ID tenanta, které je v něm obsažené, a pak byste klíč digitálně podepsali pomocí přístupu, jako je HMAC. Při zpracování každého požadavku ověříte podpis a pak extrahujete ID tenanta.

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

• Jak vygenerujete a vydáte 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 vypršela po určité době? Jak budete obměňovat klíče rozhraní API klientů bez výpadků?
• Spoléhat se jen na klíče rozhraní API, které jsou součástí zákazníka, poskytuje pro vaše rozhraní API odpovídající úroveň zabezpečení?

Klientské certifikáty

Ověřování klientských certifikátů, někdy označované jako vzájemné tls (mTLS), se běžně používá ke komunikaci mezi službami. Klientské certifikáty poskytují bezpečný 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, která se dá použít k vyhledá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é jsou vaší službou důvěryhodné? Klientské certifikáty můžou být složité pro práci, 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 žádostem o 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 servery

Reverzní proxy server, označovaný také jako proxy aplikace, lze použít ke směrování požadavků HTTP. Reverzní proxy server přijímá požadavek z koncového bodu příchozího přenosu dat a může požadavek předat jednomu z mnoha back-endových koncových bodů. Reverzní proxy servery jsou užitečné pro víceklientských aplikací, protože můžou provádět mapování mezi některými informacemi o žádostech a snižováním zátěže úlohy z infrastruktury aplikace.

Mnoho reverzních proxy serverů může použít vlastnosti požadavku k rozhodování o směrování tenanta. Můžou zkontrolovat název cílové domény, cestu URL, řetězec dotazu, hlavičky HTTP a dokonce deklarace identity v tokenech.

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

• 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í.
• Aplikace Azure lication Gateway je nástroj pro vyrovnávání zatížení spravovaného webového provozu, který nasazujete do stejné fyzické oblasti jako back-endová služba.
• Azure API Management je optimalizovaný pro provoz rozhraní API.
• Mezi komerční a opensourcové technologie (které hostujete sami) patří nginx, Traefik a HAProxy.

Ověření požadavku

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 k mapování požadavků na tenanta používá vlastní název domény, musí vaše aplikace stále kontrolovat, jestli je pro tohoto tenanta autorizovaný každý požadavek přijatý aplikací. I když požadavek obsahuje název domény nebo jiný identifikátor tenanta, neznamená to, že byste měli automaticky udělit přístup. Při použití OAuth 2.0 provedete ověření kontrolou cílové skupiny a deklarace rozsahu.

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

• Jak autorizujete všechny požadavky na vaši aplikaci? Žádosti musíte autorizovat bez ohledu na přístup, který používáte k jejich mapování na fyzickou infrastrukturu.
• Používejte důvěryhodné, široce používané a dobře udržované architektury ověřování a autorizace a middleware místo implementace všech ověřovací logiky sami. Například nevytvávejte logiku ověřování podpisu tokenu ani kryptografické knihovny klientských certifikátů. Místo toho použijte funkce aplikační platformy (nebo známých důvěryhodných balíčků), které byly ověřeny a testovány.

Výkon

Logika mapování tenanta se pravděpodobně spouští na všech žádostech vaší aplikace. Zvažte, jak dobře bude proces mapování tenanta škálovat, jak bude vaše řešení růst. Pokud například v rámci mapování tenanta zadáte dotaz na tabulku databáze, 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ě skromný, nebude to pravděpodobně mít vliv na celkový výkon. Pokud ale máte aplikaci ve velkém měřítku, může být režie spojená s tímto mapováním významná.

Spřažení relací

Jedním z přístupů ke snížení režijních nákladů na výkon logiky mapování tenanta je použití spřažení relací. Místo toho, abyste mapování provedli u každého požadavku, zvažte výpočet informací pouze u prvního požadavku pro každou relaci. Aplikace pak klientovi poskytne soubor cookie relace. Klient předá soubor cookie relace zpět do vaší služby se všemi dalšími požadavky klientů v rámci této relace.

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

• Můžete použít spřažení relací ke snížení režijních nákladů 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

Tenanti 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í, můžou se změnit koncové body HTTP, ke kterým přistupuje. V takovém případě zvažte, že je potřeba aktualizovat proces mapování tenanta. Možná budete muset zvážit následující:

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

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Daniel Scott-Raynsford | Partner Technology Strategist

Další přispěvatelé:

• John Downs | Hlavní softwarový inženýr
• Paul Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Přečtěte si o aspektech při práci s názvy domén ve víceklientských aplikacích.