Mapuj żądania do dzierżaw w rozwiązaniu wielodostępnym

Za każdym razem, gdy żądanie zostanie dostarczone do aplikacji, musisz określić dzierżawę, dla której jest przeznaczone żądanie. Jeśli masz infrastrukturę specyficzną dla dzierżawy, która może być nawet hostowana w różnych regionach geograficznych, musisz dopasować przychodzące żądanie do dzierżawy. Następnie należy przekazać żądanie do infrastruktury fizycznej, która hostuje zasoby tej dzierżawy, jak pokazano poniżej:

Na tej stronie udostępniamy wskazówki dla osób podejmujących decyzje techniczne dotyczące podejść, które można wziąć pod uwagę, aby mapować żądania do odpowiedniej dzierżawy oraz kompromisy związane z podejściami.

Podejścia do identyfikowania dzierżaw

Istnieje wiele sposobów identyfikowania dzierżawy dla żądania przychodzącego.

Nazwy domen

Jeśli używasz nazw domen lub poddomeny specyficznej dla dzierżawy, prawdopodobnie żądania mogą być łatwo mapowane na dzierżawy przy użyciu Host nagłówka 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, którego używają wszyscy dzierżawcy? Jeśli tak, w jaki sposób użytkownicy będą identyfikować dzierżawę, do której potrzebują dostępu?
• Jakich innych informacji używasz do weryfikowania dostępu do dzierżawy, 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 dzierżawy, nadal może być możliwe użycie aspektów żądania HTTP w celu zidentyfikowania dzierżawy, dla której znajduje się określone żądanie. Rozważmy na przykład żądanie HTTP, które identyfikuje nazwę dzierżawy jako tailwindtraders. Może to być przekazywane przy użyciu następujących informacji:

• 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 X-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żaw, centralna strona docelowa musi skierować użytkowników do odpowiedniej dzierżawy, dodając ciąg zapytania?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, którego używają wszyscy dzierżawcy? Jeśli tak, w jaki sposób użytkownicy będą identyfikować dzierżawę, do której 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ć bramy interfejsu API lub zwrotnego serwera proxy do wykonania mapowania dzierżawy.

Oświadczenia tokenu

Wiele aplikacji używa protokołów uwierzytelniania i autoryzacji opartych na oświadczeniach, takich jak OAuth 2.0 lub SAML. Te protokoły udostępniają klientom tokeny autoryzacji. Token zawiera zestaw oświadczeń, które są informacjami o aplikacji klienckiej lub użytkowniku. Oświadczenia 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 typu użytkownik-dzierżawa, a następnie przekazać żądanie do odpowiedniego wdrożenia. Możesz nawet uwzględnić mapowanie dzierżawy w systemie tożsamości i dodać oświadczenie o identyfikatorze dzierżawy do tokenu.

Jeśli używasz oświadczeń do mapowania żądań do dzierżaw, należy wziąć pod uwagę następujące pytania:

• Czy użyjesz oświadczenia, aby zidentyfikować dzierżawę? Którego oświadczenia użyjesz?
• Czy użytkownik może być członkiem wielu dzierżaw? Jeśli jest to możliwe, w jaki sposób użytkownicy będą wybierać dzierżawy, z którymi chcą pracować?
• Czy istnieje centralny system uwierzytelniania i autoryzacji dla wszystkich dzierżaw? Jeśli nie, w jaki sposób zapewnisz, że wszystkie urzędy tokenów wystawiają spójne tokeny i oświadczenia?

Klucze interfejsu API

Wiele aplikacji uwidacznia 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 i mogą służyć do wyszukiwania dzierżawy.

Klucze interfejsu API można wygenerować na kilka sposobów. Typowym podejściem jest wygenerowanie kryptograficznie losowej wartości i zapisanie jej w tabeli odnośników wraz z identyfikatorem dzierżawy. Po odebraniu żądania system znajdzie klucz interfejsu API w tabeli odnośników, a następnie dopasuje go do identyfikatora dzierżawy. Innym podejściem jest utworzenie znaczącego ciągu z dołączonym do niego identyfikatorem dzierżawy, a następnie cyfrowe podpisanie klucza przy użyciu podejścia takiego jak HMAC. Podczas przetwarzania każdego żądania należy zweryfikować podpis, a następnie wyodrębnić identyfikator dzierżawy.

Zastanów się nad następującymi pytaniami:

• Jak będą generowane i wystawiane klucze interfejsu API?
• Jak klienci interfejsu API będą bezpiecznie odbierać i przechowywać klucz interfejsu API?
• Czy potrzebujesz kluczy interfejsu API, aby wygasnąć po upływie okresu? Jak będzie obracać klucze interfejsu API klientów bez powodowania przestojów?
• Czy po prostu poleganie na kluczach interfejsu API wdrożonych przez klienta zapewnia odpowiedni poziom zabezpieczeń dla interfejsów API?

Certyfikaty klienta

Uwierzytelnianie certyfikatu klienta, czasami nazywane wzajemnym protokołem TLS (mTLS), jest często używane do komunikacji między usługami. 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 kwestie:

• Jak bezpiecznie wydasz i odnowisz certyfikaty klienta, które są zaufane przez usługę? Certyfikaty klienta mogą być złożone do pracy, ponieważ wymagają specjalnej infrastruktury do zarządzania certyfikatami i wystawiania ich.
• Czy certyfikaty klienta będą używane tylko do początkowych żądań logowania, czy dołączone do wszystkich żądań do usługi?
• Czy proces wystawiania certyfikatów i zarządzania nimi stanie się niezarządzany, gdy masz dużą liczbę klientów?
• Jak wdrożysz mapowanie między certyfikatem klienta a dzierżawą?

Odwrotne serwery proxy

Zwrotny serwer proxy, nazywany również serwerem proxy aplikacji, może służyć do kierowania żądań HTTP. Zwrotny serwer proxy akceptuje żądanie z punktu końcowego ruchu przychodzącego i może przekazywać żądanie do jednego z wielu punktów końcowych zaplecza. Odwrotne serwery proxy są przydatne w przypadku aplikacji wielodostępnych, ponieważ mogą wykonywać mapowanie między niektórymi informacjami żądania, odciążając zadanie z infrastruktury aplikacji.

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

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.
• aplikacja systemu Azure Gateway to zarządzany moduł równoważenia obciążenia ruchu internetowego wdrażany w tym samym regionie fizycznym co usługa zaplecza.
• Usługa Azure API Management jest zoptymalizowana pod kątem ruchu interfejsu API.
• 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żawy. Jeśli na przykład aplikacja używa niestandardowej nazwy domeny do mapowania żądań do dzierżawy, aplikacja musi nadal sprawdzać, czy każde żądanie odebrane przez aplikację jest autoryzowane dla tej dzierżawy. 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 odbiorców i zakresów .

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

• 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 struktur 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 funkcji platformy aplikacji (lub znanych zaufanych pakietów), które zostały zweryfikowane i przetestowane.

Wydajność

Logika mapowania dzierżawy 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żawy, baza danych będzie obsługiwać dużą ilość obciążenia? Jeśli mapowanie dzierżawy wymaga odszyfrowywania tokenu, wymagania dotyczące obliczeń staną się zbyt wysokie w czasie? Jeśli ruch jest dość skromny, 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.

Koligacja sesji

Jednym z podejść do zmniejszenia obciążenia związanego z wydajnością logiki mapowania dzierżawy jest użycie koligacji 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.

Zastanów się nad następującymi pytaniami:

• Czy można użyć koligacji sesji, aby zmniejszyć obciążenie związane z mapowaniem żądań do dzierżaw?
• Jakich usług używasz do kierowania żądań do wdrożeń fizycznych dla każdej dzierżawy? Czy te usługi obsługują koligację sesji opartą na plikach cookie?

Migracja dzierżawy

Dzierżawy często muszą być przenoszone do nowej infrastruktury w ramach cyklu życia dzierżawy. 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 dzierżawy musi zostać zaktualizowany. Może być konieczne rozważenie następujących kwestii:

• 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 wpisów DNS w usłudze DNS.
• Jeśli migracja zmieni adresy wszystkich punktów końcowych podczas procesu migracji, rozważ tymczasowe przekierowanie żądań dzierżawy do strony konserwacji, która zostanie automatycznie odświeżona.

Współautorzy

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

Główny autor:

• Daniel Scott-Raynsford | Partner TechnologyStrateg

Inni współautorzy:

• John Downs | Główny inżynier klienta, fasttrack dla platformy Azure
• Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

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

Następne kroki

Dowiedz się więcej o zagadnieniach dotyczących pracy z nazwami domen w aplikacji wielodostępnej.