Dela via

Mappa begäranden till klienter i en lösning med flera klienter

Azure

Whenever a request arrives into your application, you need to determine the tenant context, which is the tenant that is making the request. När du har en klientspecifik infrastruktur som till och med kan finnas i olika geografiska regioner måste du matcha den inkommande begäran till en klientorganisation. Sedan måste du vidarebefordra begäran till den fysiska infrastruktur som är värd för klientorganisationens resurser, enligt nedan:

Diagram som visar mappning av en begäran från klientorganisationer till distributioner.

Många program med flera klienter har också användarbaserade behörigheter. Klientmappning är en separat aktivitet. Du måste känna till både den användare som gör begäran och den klientorganisation som de arbetar inom.

Den här artikeln innehåller vägledning för tekniska beslutsfattare om de metoder som du kan överväga för att mappa begäranden till lämplig klientorganisation och de kompromisser som ingår i metoderna.

Note

På den här sidan diskuteras främst HTTP-baserade program, till exempel webbplatser och API:er. Många av de underliggande principerna gäller dock för program med flera klienter som använder andra kommunikationsprotokoll.

Metoder för att identifiera klienter

Det finns flera sätt att identifiera klientorganisationen för en inkommande begäran. Varje metod kräver att du inspekterar någon aspekt av den inkommande begäran.

Domain names

Om du använder klientspecifika domän- eller underdomännamn är det troligt att begäranden enkelt kan mappas till klienter med hjälp Host av huvudet, X-Forwarded-Host huvudet eller ett annat HTTP-huvud som innehåller det ursprungliga värdnamnet för varje begäran.

Tänk dock på följande frågor:

  • Hur vet användarna vilket domännamn som ska användas för att komma åt tjänsten?
  • Har du en central startpunkt, till exempel en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur väljer användarna den klientorganisation som de arbetar med?
  • Vilken annan information använder du för att verifiera åtkomsten till klientorganisationens resurser, till exempel auktoriseringstoken? Innehåller auktoriseringstoken de klientspecifika domännamnen?

Egenskaper för HTTP-begäran

Om du inte använder klientspecifika domännamn kanske du fortfarande kan använda aspekter av HTTP-begäran för att identifiera klientorganisationen som en viss begäran gäller. Du kan till exempel överväga en HTTP-begäran som identifierar klientnamnet som tailwindtraders. Detta kan kommuniceras med någon av följande metoder:

  • URL-sökvägsstrukturen, till exempel https://app.contoso.com/tailwindtraders/.
  • En frågesträng i URL:en, till exempel https://contoso.com/app?tenant=tailwindtraders.
  • Ett anpassat HTTP-begärandehuvud, till exempel Tenant-Id: tailwindtraders.

Important

Anpassade HTTP-begärandehuvuden är inte användbara när HTTP GET-begäranden utfärdas från en webbläsare eller där begäranden hanteras av vissa typer av webbproxy. Du bör bara använda anpassade HTTP-huvuden för GET-åtgärder när du skapar ett API, eller om du styr klienten som utfärdar begäran och det inte finns någon webbproxy i bearbetningskedjan för begäran som kan ändra eller ta bort rubrikerna.

När du använder den här metoden bör du överväga följande frågor:

  • Vet användarna hur de ska komma åt tjänsten? Om du till exempel använder en frågesträng för att identifiera klienter måste en central landningssida dirigera användarna till rätt klientorganisationssida genom att lägga till frågesträngen?
  • Har du en central startpunkt, till exempel en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur väljer användarna den klientorganisation som de behöver åtkomst till?
  • Tillhandahåller ditt program API:er? Är ditt webbprogram till exempel ett ensidesprogram (SPA) eller ett mobilprogram med en API-serverdel? If it is, you might be able to use an API gateway or reverse proxy to perform tenant mapping.

Token claims

Många program använder anspråksbaserad autentisering och auktoriseringsprotokoll, till exempel OAuth 2.0 eller SAML. Dessa protokoll tillhandahåller auktoriseringstoken till klienten. A token contains a set of claims, which are pieces of information about the client application or user. Anspråk kan användas för att kommunicera information som en användares e-postadress. Systemet kan sedan inkludera användarens e-postadress, leta upp mappningen mellan användare och klientorganisation och sedan vidarebefordra begäran till lämplig distribution. Eller så kan du till och med inkludera klientmappningen i ditt identitetssystem och lägga till ett klient-ID-anspråk i token.

Om du använder anspråk för att mappa begäranden till klientorganisationer bör du överväga följande frågor:

  • Kommer du att använda ett anspråk för att identifiera en klientorganisation? Vilket anspråk ska du använda?
  • Kan en användare vara medlem i flera klientorganisationer? Hur väljer användarna den klientorganisation som de vill arbeta med för en specifik begäran om detta är möjligt?
  • Finns det ett centralt autentiserings- och auktoriseringssystem för alla klienter? Om inte, hur ser du till att alla tokenmyndigheter utfärdar konsekventa token och anspråk?

API keys

Många program exponerar API:er. Dessa kan vara för internt bruk i din organisation eller för extern användning av partner eller kunder. A common method of authentication for APIs is to use an API key. API-nycklar tillhandahålls med varje begäran. Om du registrerar klient-ID:t som en nyckel har utfärdats för kan du sedan leta upp klientorganisations-ID:t när nyckeln används.

Note

API-nycklar ger ingen hög säkerhetsnivå eftersom de måste skapas och hanteras manuellt, de är långlivade och återanvänds ofta och eftersom de inte innehåller anspråk. En modernare och säkrare metod är att använda en anspråksbaserad auktoriseringsmekanism med kortlivade token, till exempel OAuth 2.0 eller OpenID Connect.

API-nycklar kan genereras på flera sätt. Här är två vanliga metoder:

  • Generera ett kryptografiskt slumpmässigt värde och lagra det i en uppslagstabell tillsammans med klientorganisations-ID:t. När en begäran tas emot hittar systemet API-nyckeln i uppslagstabellen och matchar den sedan med ett klient-ID.
  • Skapa en meningsfull sträng med ett klient-ID som ingår i den. Digitally sign the key by using an approach like HMAC. När du bearbetar varje begäran verifierar du signaturen och extraherar sedan klientorganisations-ID:t.

Tänk på följande frågor:

  • Hur genererar och utfärdar du API-nycklar?
  • Hur tar dina API-klienter emot och lagrar API-nyckeln på ett säkert sätt?
  • Behöver du att dina API-nycklar upphör att gälla efter en viss tidsperiod? Hur roterar du dina klienters API-nycklar utan att orsaka stilleståndstid?
  • Ger kundgenererade API-nycklar en lämplig säkerhetsnivå för dina API:er?

Note

API-nycklar är inte samma som lösenord. API-nycklar måste genereras av systemet och de måste vara unika för alla klienter, så att varje API-nyckel kan mappas unikt till en enda klientorganisation. API-gatewayer, till exempel Azure API Management, kan generera och hantera API-nycklar, verifiera nycklar på inkommande begäranden och mappa nycklar till enskilda API-prenumeranter.

Client certificates

Klientcertifikatautentisering, som ibland kallas ömsesidig TLS (mTLS), används ofta för tjänst-till-tjänst-kommunikation och för obevakade enheter eller kiosker som används av oautentiserade användare. Klientcertifikat är ett säkert sätt att autentisera klienter. Similarly to tokens and claims, client certificates provide attributes that can be used to determine the tenant. For example, the subject of the certificate may contain the email address of the user, which can be used to look up the tenant.

När du planerar att använda klientcertifikat för klientmappning bör du tänka på följande:

  • Hur kan du på ett säkert sätt utfärda och förnya klientcertifikaten som är betrodda av din tjänst? Klientcertifikat kan vara komplexa att arbeta med, eftersom de kräver särskild infrastruktur för att hantera och utfärda certifikat. If handled improperly, these complexities can reduce your security instead of increasing it.
  • Kommer klientcertifikat endast att användas för inledande inloggningsbegäranden eller kopplas till alla begäranden till din tjänst?
  • Kommer processen med att utfärda och hantera certifikat att bli ohanterlig när du har ett stort antal klienter?
  • Hur implementerar du mappningen mellan klientcertifikatet och klientorganisationen?

Reverse proxies

En omvänd proxy, även kallad programproxy, kan användas för att dirigera HTTP-begäranden. En omvänd proxy accepterar en begäran från en ingressslutpunkt och kan vidarebefordra begäran till en av många serverdelsslutpunkter. Omvända proxyservrar är användbara för program med flera klienter eftersom de kan utföra mappningen mellan viss information om begäranden och avlasta uppgiften från programinfrastrukturen.

Många omvända proxyservrar kan använda egenskaperna för en begäran för att fatta ett beslut om klientdirigering. De kan granska måldomännamnet, URL-sökvägen, frågesträngen, HTTP-huvuden och till och med anspråk i token eller delar av begärandetexten.

Följande vanliga omvända proxyservrar används i Azure:

  • Azure Front Door är en global lastbalanserare och brandvägg för webbprogram. Det använder Microsofts globala edge-nätverk för att skapa snabba, säkra och mycket skalbara webbprogram. You can use rule sets to extract tenant identifiers and put them into another part of the request.
  • Azure Application Gateway är en hanterad lastbalanserare för webbtrafik som du distribuerar till samma fysiska region som serverdelstjänsten.
  • Azure API Management är optimerat för API-trafik. Azure API Management provides a comprehensive policy engine that provides a great deal of flexibility for extracting tenant information from requests.
  • Kommersiella tekniker och tekniker med öppen källkod (som du är värd för själv) omfattar nginx, Traefik och HAProxy.

Request validation

Det är viktigt att ditt program verifierar att alla begäranden som det tar emot är auktoriserade för klientorganisationen. Om ditt program till exempel använder ett anpassat domännamn för att mappa begäranden till klientorganisationen måste programmet fortfarande kontrollera att varje begäran som tas emot av programmet är auktoriserad för den klientorganisationen. Även om begäran innehåller ett domännamn eller annan klientidentifierare betyder det inte att du automatiskt ska bevilja åtkomst. When you use OAuth 2.0, you perform the validation by inspecting the audience and scope claims.

Note

Detta är en del av principen för säkerhetsdesign med noll förtroende i Microsoft Azure Well-Architected Framework.

När du implementerar validering av begäranden bör du överväga följande:

  • Hur kommer du att auktorisera alla begäranden till ditt program? Du måste auktorisera begäranden, oavsett vilken metod du använder för att mappa dem till fysisk infrastruktur.
  • Använd betrodda, allmänt använda och väl underhållna autentiserings- och auktoriseringsramverk och mellanprogram, i stället för att implementera all valideringslogik själv. Skapa till exempel inte valideringslogik för tokensignatur eller kryptografibibliotek för klientcertifikat. Använd i stället funktioner för din programplattform (eller kända betrodda paket) som har verifierats och testats.

Performance

Logik för klientmappning körs troligen på varje begäran till ditt program. Fundera på hur väl klientmappningsprocessen kommer att skalas i takt med att lösningen växer. Om du till exempel kör frågor mot en databastabell som en del av klientmappningen, kommer databasen att ha stöd för en stor mängd belastning? Kommer beräkningskraven att bli för höga över tid om klientmappningen kräver dekryptering av en token? Om din trafik är ganska blygsam kommer detta sannolikt inte att påverka din övergripande prestanda. När du har ett storskaligt program kan dock kostnaderna för den här mappningen bli betydande.

Session cookies

One approach to reducing the performance overhead of tenant mapping logic is to use session cookies. I stället för att utföra mappningen på varje begäran bör du överväga att endast beräkna informationen på den första begäran för varje session. Ditt program tillhandahåller sedan en sessionscookie till klienten. Klienten skickar sessionscookien tillbaka till din tjänst med alla efterföljande klientbegäranden inom den sessionen.

Note

Många nätverk och programtjänster i Azure kan utfärda sessionscookies.

Tänk på följande frågor:

  • Kan du använda sessionscookies för att minska kostnaderna för att mappa begäranden till klienter?
  • Vilka tjänster använder du för att dirigera begäranden till de fysiska distributionerna för varje klientorganisation? Stöder dessa tjänster cookiebaserade sessioner?

Tenant migration

Tenants often need to be moved to new infrastructure as part of the tenant lifecycle. När en klientorganisation flyttas till en ny distribution kan DE HTTP-slutpunkter som de kommer åt ändras. När detta händer bör du tänka på att processen för klientmappning måste ändras. Du kan behöva tänka på följande faktorer:

  • Om ditt program använder domännamn för mappningsbegäranden kan det också kräva en DNS-ändring vid tidpunkten för migreringen. DNS-ändringen kan ta tid att sprida till klienter, beroende på TTL (time-to-live) för DNS-posterna i DNS-tjänsten.
  • Om din migrering ändrar adresserna för alla slutpunkter under migreringsprocessen kan du överväga att tillfälligt omdirigera begäranden för klientorganisationen till en underhållssida som uppdateras automatiskt.

Contributors

Den här artikeln underhålls av Microsoft. Texten skrevs ursprungligen av följande bidragsgivare.

Principal author:

Other contributors:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Next steps

Lär dig mer om överväganden när du arbetar med domännamn i ett program med flera klienter.