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

När en begäran tas emot i programmet måste du fastställa vilken klientorganisation som begäran är avsedd för. 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:

På den här sidan ger vi vägledning till tekniska beslutsfattare om de metoder som du kan överväga att mappa begäranden till rätt klientorganisation och de kompromisser som är inblandade i metoderna.

Metoder för att identifiera klienter

Det finns flera sätt att identifiera klientorganisationen för en inkommande begäran.

Domännamn

Om du använder klientspecifika domän- eller underdomännamn är det troligt att begäranden enkelt kan mappas till klienter med hjälp av -huvudet eller ett annat HTTP-huvudsom 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 få åtkomst till tjänsten?
• Har du en central startpunkt, som en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur identifierar användarna den klientorganisation som de behöver åtkomst till?
• Vilken annan information använder du för att verifiera åtkomsten till klientorganisationen, till exempel auktoriseringstoken? Innehåller auktoriseringstoken de klientspecifika domännamnen?

Egenskaper för HTTP-begäran

Om du inte använder klientspecifika domännamn kan du fortfarande använda olika aspekter av HTTP-begäran för att identifiera den klientorganisation som en viss begäran gäller. Överväg till exempel en HTTP-begäran som identifierar klientorganisationens namn som tailwindtraders . Detta kan kommuniceras med hjälp av följande:

• URL-sökvägens struktur,till exempel .
• En frågesträng i URL:en, till exempel .
• Ett anpassat HTTP-begärandehuvud,till exempel .

När du använder den här metoden bör du tänka på följande frågor:

• Kommer användarna att veta hur de kommer åt tjänsten? Om du till exempel använder en frågesträng för att identifiera klienter, behöver en central landningssida dirigera användarna till rätt klientorganisation genom att lägga till frågesträngen?
• Har du en central startpunkt, som en landningssida eller inloggningssida, som alla klienter använder? Om du gör det, hur identifierar användarna den klientorganisation som de behöver åtkomst till?
• Tillhandahåller ditt program API:er? Är din webbapp till exempel en ensidesapplikation (SPA) eller ett mobilprogram med en API-backend? Om det är det kan du kanske använda en API-gateway eller omvänd proxy för att utföra klientmappning.

Tokenanspråk

Många program använder anspråksbaserade autentiserings- och auktoriseringsprotokoll, till exempel OAuth 2.0 eller SAML. Dessa protokoll tillhandahåller auktoriseringstoken till klienten. En token innehåller en uppsättning anspråk, som är uppgifter om klientprogrammet eller användaren. 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 klient och sedan vidarebefordra begäran till lämplig fysisk klientinfrastruktur. 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 klienter bör du tänka på följande frågor:

• Kommer du att använda ett anspråk för att identifiera en klient? Vilket anspråk ska du använda?
• Kan en användare vara medlem i flera klienter? Om detta är möjligt, hur väljer användarna de klienter som de vill arbeta med?
• Finns det ett centralt system för autentisering och auktorisering för alla klienter? Om inte, hur ser du till att alla token-myndigheter utfärdar konsekventa token och anspråk?

API-nycklar

Många program exponerar API:er. Dessa kan vara för intern användning i din organisation eller för extern användning av partner eller kunder. En vanlig autentiseringsmetod för API:er är att använda en API-nyckel. API-nycklar tillhandahålls med varje begäran och de kan användas för att leta upp klientorganisationen.

API-nycklar kan genereras på flera olika sätt. En vanlig metod är att 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 klientorganisations-ID. En annan metod är att skapa en meningsfull sträng med ett klientorganisations-ID som ingår i den och sedan signera nyckeln digitalt med hjälp av en metod som HMAC. När du bearbetar varje begäran verifierar du signaturen och extraherar sedan klientorganisations-ID:t.

Överväg följande frågor:

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

Klientcertifikat

Klientcertifikatautentisering, som ibland kallas ömsesidig TLS (mTLS), används ofta för tjänst-till-tjänst-kommunikation. Klientcertifikat är ett säkert sätt att autentisera klienter. På samma sätt som med token och anspråk tillhandahåller klientcertifikat attribut som kan användas för att fastställa klientorganisationen. Certifikatets ämne kan till exempel innehålla användarens e-postadress, som kan användas för att leta upp klienten.

Tänk på följande när du planerar att använda klientcertifikat för klientmappning:

• Hur kommer du på ett säkert sätt att utfärda och förnya de klientcertifikat 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.
• Kommer klientcertifikat endast att användas för inledande inloggningsbegäranden eller kopplas till alla begäranden till din tjänst?
• Kommer processen att utfärda och hantera certifikat bli ohanterbar när du har ett stort antal klienter?
• Hur implementerar du mappningen mellan klientcertifikatet och klientorganisationen?

Omvända proxy

En omvänd proxy, som även kallas en 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 slutpunkter i en backend. Omvända proxy är användbara för program med flera olika program eftersom de kan utföra mappningen mellan viss information om begäran, vilket avlastar uppgiften från programinfrastrukturen.

Många omvända proxys kan använda egenskaperna för en begäran för att fatta ett beslut om klientdirigering. De kan inspektera måldomännamnet, URL-sökvägen, frågesträngen, HTTP-huvudena och till och med anspråk inom token.

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

• Azure Front Door är en global lastbalanserare och brandvägg för webbaserade program. Den använder Microsofts globala gränsnätverk för att skapa snabba, säkra och mycket skalbara webbprogram.
• Azure Application Gateway är en lastbalanserare för hanterad webbtrafik som du distribuerar till samma fysiska region som din backend-tjänst.
• Azure API Management är optimerat för API-trafik.
• Kommersiella tekniker och tekniker med öppen källkod (som du är värd för själv) omfattar nginx, Traefik och HAProxy.

Begärandeverifiering

Det är viktigt att ditt program verifierar att alla begäranden som det tar emot har auktoriserats 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 har behörighet för den klientorganisationen. Även om begäran innehåller ett domännamn eller annan klientorganisationsidentifierare betyder det inte att du automatiskt ska bevilja åtkomst. När du använder OAuth 2.0 utför du verifieringen genom att granska målgruppen ochomfångsanspråken.

När du implementerar validering av begäran bör du tänka på följande:

• Hur godkänner du alla begäranden till ditt program? Du måste auktorisera begäranden, oavsett vilken metod du använder för att mappa dem till den fysiska infrastrukturen.
• Använd betrodda och ofta använda ramverk för autentisering och auktorisering 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 istället funktionerna i din programplattform (eller kända betrodda paket) som har verifierats och testats.

Prestanda

Logik för klientmappning körs troligen på varje begäran till ditt program. Fundera över hur väl klientmappningsprocessen kommer att skalas när din lösning växer. Om du till exempel frågar en databastabell som en del av klientmappningen, kommer databasen att stödja 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 trafiken är ganska liten påverkar detta förmodligen inte den övergripande prestandan. När du har ett storskaligt program kan dock omkostnaderna för den här mappningen bli betydande.

Sessionstillhörighet

En metod för att minska prestandakostnaderna för klientmappningslogik är att använda sessionstillhörighet. I stället för att utföra mappningen på varje begäran bör du överväga att beräkna informationen endast på den första begäran för varje session. Ditt program tillhandahåller sedan en sessionscookie till klienten som sedan kan skickas tillbaka till din tjänst, med alla efterföljande klientbegäranden inom den sessionen.

Överväg följande frågor:

• Kan du använda sessionstillhörighet för att minska omkostnaderna för mappningsbegäranden till klienter?
• Vilka tjänster använder du för att dirigera begäranden till de fysiska distributionerna för varje klient? Stöder dessa tjänster cookiebaserad sessionstillhörighet?

Klientmigrering

Klienter behöver ofta flyttas till ny infrastruktur som en del av klientlivscykeln. När en klientorganisation flyttas till en ny distribution kan de HTTP-slutpunkter som de har åtkomst till ändras. När detta inträffar bör du tänka på att klientmappningsprocessen måste uppdateras. Du kan behöva tänka på följande:

• Om ditt program använder domännamn för mappningsbegäranden kan det också kräva en DNS-ändring vid tidpunkten för migreringen. DET kan ta tid att sprida DNS-ändringen till klienter, beroende på hur lång tid dns-posterna i DNS-tjänsten tar.
• Om migreringen ändrar adresserna för slutpunkter under migreringsprocessen bör du överväga att tillfälligt omdirigera begäranden för klienten till en underhållssida som uppdateras automatiskt.

Nästa steg

Lär dig mer om saker att tänka på när du arbetar med domännamn i ett program med flera olika program.