Mapuj żądania do dzierżawców w rozwiązaniu dla wielu dzierżawców

Za każdym razem, gdy żądanie dotrze do aplikacji, musisz zidentyfikować kontekst najemcy, czyli najemcę wysyłającego żądanie. Jeśli masz infrastrukturę specyficzną dla klienta, która może być hostowana w różnych regionach geograficznych, musisz przypisać przychodzące żądanie do konkretnego tenanta. Następnie należy przekazać żądanie do infrastruktury fizycznej, która hostuje zasoby tego najemcy, jak pokazano na poniższym diagramie:

Wiele aplikacji wielodzierżawnych ma również uprawnienia per użytkownik. Mapowanie dzierżawcy to osobne działanie. Musisz znać zarówno użytkownika, który wysyła żądanie, jak i dzierżawcę, w ramach którego pracuje.

Ten artykuł zawiera wskazówki dla osób podejmujących decyzje techniczne dotyczące podejść, które można rozważyć, aby przypisywać żądania do odpowiedniego tenantu, oraz kompromisów związanych z tymi podejściami.

Podejścia do identyfikowania tenantów

Istnieje wiele sposobów identyfikowania dzierżawcy na podstawie żądania przychodzącego. Każde podejście wymaga sprawdzenia pewnego aspektu żądania przychodzącego.

Nazwy domen

Jeśli używasz nazw domen lub subdomen specyficznych dla dzierżawcy, prawdopodobnie żądania można łatwo mapować na dzierżawców przy użyciu nagłówka Host, nagłówka X-Forwarded-Host lub innego nagłówka HTTP zawierającego oryginalną nazwę hosta dla każdego żądania.

Należy jednak wziąć pod uwagę następujące pytania:

• Jak użytkownicy będą wiedzieć, która nazwa domeny ma być używana do uzyskiwania dostępu do usługi?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, z którego korzystają wszystkie tenanty? W jaki sposób użytkownicy będą wybierać tenant, z którym pracują?
• Jakich innych informacji używasz do weryfikowania dostępu do zasobów dzierżawcy, takich jak tokeny autoryzacji? Czy tokeny autoryzacji zawierają nazwy domen specyficznych dla dzierżawy?

Właściwości żądania HTTP

Jeśli nie używasz nazw domen specyficznych dla tenanta, nadal może być możliwe użycie aspektów żądania HTTP w celu zidentyfikowania tenanta, którego dotyczy dane żądanie. Rozważmy na przykład żądanie HTTP, które identyfikuje nazwę dzierżawcy jako tailwindtraders. Może to być przekazywane przy użyciu jednej z następujących metod:

• Struktura ścieżki adresu URL, taka jak https://app.contoso.com/tailwindtraders/.
• Ciąg zapytania w adresie URL, taki jak https://contoso.com/app?tenant=tailwindtraders.
• Niestandardowy nagłówek żądania HTTP, taki jak Tenant-Id: tailwindtraders.

W przypadku korzystania z tego podejścia należy wziąć pod uwagę następujące pytania:

• Czy użytkownicy będą wiedzieć, jak uzyskać dostęp do usługi? Jeśli na przykład używasz ciągu zapytania do identyfikowania dzierżawców, czy centralna strona docelowa będzie musiała skierować użytkowników do odpowiedniej strony dzierżawcy przez dodanie ciągu zapytania?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, z którego korzystają wszyscy klienci? Jeśli tak, w jaki sposób użytkownicy będą wybierać dzierżawcę, do którego potrzebują dostępu?
• Czy aplikacja udostępnia interfejsy API? Czy na przykład aplikacja internetowa jest aplikacją jednostronicową (SPA), czy aplikacją mobilną z zapleczem interfejsu API? Jeśli tak jest, możesz użyć API gateway lub reverse proxy do wykonania mapowania tenantów.

Oświadczenia tokenu

Wiele aplikacji używa protokołów uwierzytelniania i autoryzacji opartych na deklaracjach, takich jak OAuth 2.0 lub SAML. Te protokoły udostępniają klientowi tokeny autoryzacji. Token zawiera zestaw oświadczeń, które są informacjami o aplikacji klienckiej lub użytkowniku. Claimy mogą służyć do przekazywania informacji, takich jak adres e-mail użytkownika. System może następnie dołączyć adres e-mail użytkownika, wyszukać mapowanie użytkownika na dzierżawcę, a następnie przekazać żądanie do odpowiedniego wdrożenia. Możesz nawet uwzględnić mapowanie dzierżawców w systemie tożsamości i dodać claim identyfikatora dzierżawcy do tokenu.

Jeśli używasz oświadczeń tożsamości do mapowania żądań do dzierżawców, należy wziąć pod uwagę następujące pytania:

• Czy użyjesz roszczenia, aby zidentyfikować dzierżawcę? Którego roszczenia użyjesz?
• Czy użytkownik może być członkiem wielu tenantów? Jeśli jest to możliwe, w jaki sposób użytkownicy będą wybierać dzierżawcę, z którym chcą pracować w ramach konkretnego żądania?
• Czy istnieje centralny system uwierzytelniania i autoryzacji dla wszystkich dzierżawców? Jeśli nie, w jaki sposób zapewnisz, że wszystkie urzędy wystawiające tokeny wystawiają spójne tokeny i atrybuty?

Klucze interfejsu API

Wiele aplikacji udostępnia interfejsy API. Mogą one być przeznaczone do użytku wewnętrznego w organizacji lub do użytku zewnętrznego przez partnerów lub klientów. Typową metodą uwierzytelniania interfejsów API jest użycie klucza interfejsu API. Klucze interfejsu API są dostarczane z każdym żądaniem. Jeśli zarejestrujesz identyfikator dzierżawcy, dla którego został wystawiony klucz, możesz następnie wyszukać identyfikator dzierżawcy, gdy klucz zostanie użyty.

Klucze interfejsu API można wygenerować na kilka sposobów. Poniżej przedstawiono dwa typowe podejścia:

• Wygeneruj kryptograficznie losową wartość i zapisz ją w tablicy wyszukiwania wraz z identyfikatorem tenantu. Po odebraniu żądania system znajdzie klucz interfejsu API w tabeli wyszukiwania, a następnie dopasuje go do identyfikatora dzierżawy.
• Utwórz znaczący ciąg z dołączonym identyfikatorem dzierżawcy. Cyfrowo podpisz klucz przy użyciu podejścia takiego jak HMAC. Podczas przetwarzania każdego żądania należy zweryfikować podpis, a następnie wyodrębnić identyfikator tenantu.

Weź pod uwagę następujące pytania:

• Jak będą generowane i wydawane klucze interfejsu API?
• Jak klienci interfejsu API będą bezpiecznie odbierać i przechowywać klucz interfejsu API?
• Czy chcesz, aby klucze API wygasały po pewnym czasie? Jak będziesz rotować klucze interfejsu API swoich klientów bez powodowania przestojów?
• Czy klucze interfejsu API generowane przez klienta zapewniają odpowiedni poziom zabezpieczeń dla interfejsów API?

Certyfikaty klienta

Uwierzytelnianie certyfikatu klienta, nazywane czasem wzajemnym protokołem TLS (mTLS), jest często używane do komunikacji między usługami oraz w przypadku urządzeń nienadzorowanych lub kiosków używanych przez nieuwierzytelnionych użytkowników. Certyfikaty klienta zapewniają bezpieczny sposób uwierzytelniania klientów. Podobnie jak w przypadku tokenów i oświadczeń, certyfikaty klienta udostępniają atrybuty , których można użyć do określenia dzierżawy. Na przykład podmiot certyfikatu może zawierać adres e-mail użytkownika, który może służyć do wyszukiwania dzierżawy.

Podczas planowania używania certyfikatów klienta do mapowania dzierżawy należy wziąć pod uwagę następujące czynniki:

• Jak bezpiecznie wydasz i odnowisz certyfikaty klienta, którym ufa Twoja usługa? Certyfikaty klienta mogą być trudne w obsłudze, ponieważ wymagają specjalnej infrastruktury do zarządzania certyfikatami i wystawiania ich. W przypadku nieprawidłowego obsługiwania te złożoności mogą zmniejszyć bezpieczeństwo zamiast go zwiększać.
• Czy certyfikaty klienta będą używane tylko do początkowych żądań logowania, czy będą dołączane do wszystkich żądań do usługi?
• Czy proces wystawiania certyfikatów i zarządzania nimi stanie się nie do opanowania, gdy masz dużą liczbę klientów?
• Jak wdrożysz mapowanie między certyfikatem klienta a dzierżawcą?

Odwrotne serwery proxy

Zwrotny serwer proxy, nazywany również serwerem proxy aplikacji, może służyć do kierowania żądań HTTP. Odwrotny serwer proxy akceptuje żądanie z punktu końcowego wejściowego i może przekazywać żądanie do jednego z wielu punktów końcowych zaplecza. Odwrotne serwery proxy są przydatne w przypadku aplikacji wielodzierżawnych, ponieważ mogą wykonywać mapowanie na podstawie części informacji żądania, zdejmując to zadanie z infrastruktury aplikacji.

Wiele serwerów proxy odwrotnych może użyć właściwości żądania, aby podjąć decyzję o routingu dzierżawcy. Mogą sprawdzić docelową nazwę domeny, ścieżkę adresu URL, ciąg zapytania, nagłówki HTTP, a nawet claims w tokenach lub częściach treści żądania.

Na platformie Azure są używane następujące typowe serwery proxy odwrotne:

• Usługa Azure Front Door to globalny moduł równoważenia obciążenia i zapora aplikacji internetowej. Używa globalnej sieci brzegowej firmy Microsoft do tworzenia szybkich, bezpiecznych i wysoce skalowalnych aplikacji internetowych. Za pomocą zestawów reguł można wyodrębnić identyfikatory dzierżawy i umieścić je w innej części żądania.
• Usługa Azure Application Gateway to zarządzany internetowy moduł równoważenia obciążenia ruchu, który jest wdrażany w tym samym regionie fizycznym co usługa backendowa.
• Usługa Azure API Management jest zoptymalizowana pod kątem ruchu interfejsu API. Usługa Azure API Management udostępnia kompleksowy aparat zasad, który zapewnia dużą elastyczność do wyodrębniania informacji o dzierżawcy z żądań.
• Technologie komercyjne i open-source (które hostujesz samodzielnie) obejmują nginx, Traefik i HAProxy.

Weryfikacja żądania

Ważne jest, aby aplikacja sprawdzała, czy wszystkie odbierane żądania są autoryzowane dla dzierżawcy. Jeśli na przykład aplikacja używa niestandardowej nazwy domeny do mapowania żądań do dzierżawcy, aplikacja musi nadal sprawdzać, czy każde żądanie odebrane przez aplikację jest autoryzowane dla tego dzierżawcy. Mimo że żądanie zawiera nazwę domeny lub inny identyfikator dzierżawy, nie oznacza to, że należy automatycznie udzielać dostępu. Jeśli używasz protokołu OAuth 2.0 przeprowadzasz walidację, sprawdzając oświadczenia audytorium i zakres.

Podczas implementowania weryfikacji żądania należy wziąć pod uwagę następujące czynniki:

• Jak autoryzujesz wszystkie żądania do aplikacji? Musisz autoryzować żądania, niezależnie od podejścia, które jest używane do mapowania ich na infrastrukturę fizyczną.
• Używaj zaufanych, powszechnie używanych i dobrze utrzymywanych frameworków uwierzytelniania i autoryzacji oraz oprogramowania pośredniczącego zamiast samodzielnego implementowania całej logiki weryfikacji. Na przykład nie twórz logiki weryfikacji podpisu tokenu ani bibliotek kryptograficznych certyfikatów klienta. Zamiast tego użyj zweryfikowanych i przetestowanych możliwości platformy Twojej aplikacji (lub znanych zaufanych pakietów).

Performance

Logika mapowania dzierżawcy jest prawdopodobnie uruchamiana na każdym żądaniu do aplikacji. Zastanów się, jak dobrze proces mapowania dzierżawy będzie skalowany w miarę rozwoju rozwiązania. Jeśli na przykład wykonasz zapytanie dotyczące tabeli bazy danych w ramach mapowania dzierżawców, baza danych obsłuży duże obciążenie? Jeśli mapowanie dzierżawy wymaga odszyfrowywania tokenu, wymagania dotyczące obliczeń staną się zbyt wysokie w czasie? Jeśli natężenie ruchu jest dość niewielkie, prawdopodobnie nie wpłynie to na ogólną wydajność. Jeśli jednak masz aplikację o dużej skali, obciążenie związane z tym mapowaniem może stać się znaczące.

Pliki cookie sesji

Jedno z podejść do zmniejszenia obciążenia logiki mapowania najemcy to użycie plików cookie sesji. Zamiast wykonywać mapowanie na każde żądanie, rozważ obliczenie informacji tylko w przypadku pierwszego żądania dla każdej sesji. Następnie aplikacja udostępnia klientowi plik cookie sesji. Klient przekazuje plik cookie sesji z powrotem do usługi ze wszystkimi kolejnymi żądaniami klienta w ramach tej sesji.

Weź pod uwagę następujące pytania:

• Czy możesz użyć plików cookie sesji, aby zmniejszyć obciążenie związane z mapowaniem żądań do dzierżawców?
• Jakich usług używasz do kierowania żądań do wdrożeń fizycznych dla każdego dzierżawcy? Czy te usługi obsługują sesje oparte na plikach cookie?

Migracja tenantów

Najemcy często muszą być przenoszeni do nowej infrastruktury w ramach cyklu życia najemcy. Po przeniesieniu dzierżawy do nowego wdrożenia punkty końcowe HTTP, do których uzyskują dostęp, mogą ulec zmianie. W takim przypadku należy wziąć pod uwagę, że proces mapowania tenanta musi ulec zmianie. Może być konieczne rozważenie następujących czynników:

• Jeśli aplikacja używa nazw domen do mapowania żądań, może również wymagać zmiany DNS w czasie migracji. Zmiana DNS może zająć trochę czasu na propagację do klientów, w zależności od czasu wygaśnięcia (TTL) wpisów DNS w usłudze DNS.
• Jeśli migracja zmieni adresy jakichkolwiek punktów końcowych podczas procesu migracji, rozważ tymczasowe przekierowanie żądań dzierżawcy do strony konserwacji, która odświeża się automatycznie.

Contributors

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Daniel Scott-Raynsford | Strateg ds. technologii partnerskich

Inni współautorzy:

• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Paolo Salvatori | Główny inżynier klienta, FastTrack dla Platformy Azure
• Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok

Dowiedz się o tożsamości w aplikacji multitenantowej.