Aanvragen aan tenants in een multitenant-oplossing

Wanneer er een aanvraag binnenkomt bij uw toepassing, moet u bepalen voor welke tenant de aanvraag is bedoeld. Wanneer u een tenantspecifieke infrastructuur hebt die zelfs in verschillende geografische regio's kan worden gehost, moet u de binnenkomende aanvraag aan een tenant matchen. Vervolgens moet u de aanvraag doorsturen naar de fysieke infrastructuur die als host dient voor de resources van die tenant, zoals hieronder wordt geïllustreerd:

Methoden om tenants te identificeren

Er zijn meerdere manieren waarop u de tenant voor een binnenkomende aanvraag kunt identificeren.

Domeinnamen

Als u tenantspecifieke domein- of subdomeinnamengebruikt, kunnen aanvragen waarschijnlijk eenvoudig worden toe te staan aan tenants. Houd echter rekening met de volgende vragen:

• Hoe weten gebruikers welke domeinnaam ze moeten gebruiken voor toegang tot de service?
• Hebt u een centraal toegangspunt, zoals een landingspagina of aanmeldingspagina, die alle tenants gebruiken? Als u dit doet, hoe identificeren gebruikers dan de tenant die ze nodig hebben?
• Welke andere informatie gebruikt u om de toegang tot de tenant te verifiëren, zoals autorisatietokens? Bevatten de autorisatietokens de tenantspecifieke domeinnamen?

EIGENSCHAPPEN VAN HTTP-aanvraag

Als u geen tenantspecifieke domeinnamen gebruikt, kunt u mogelijk nog steeds aspecten van de HTTP-aanvraag gebruiken om de tenant te identificeren waar een bepaalde aanvraag voor is. Denk bijvoorbeeld aan een HTTP-aanvraag die de tenantnaam identificeert als tailwindtraders . Dit kan worden gecommuniceerd met behulp van het volgende:

• De structuur van het URL-pad, zoals https://app.contoso.com/tailwindtraders/ .
• Een queryreeks in de URL, zoals https://contoso.com/app?tenant=tailwindtraders .
• Een aangepaste HTTP-aanvraagheader, zoals X-Tenant-Id: tailwindtraders .

Wanneer u deze methode gebruikt, moet u rekening houden met de volgende vragen:

• Weten gebruikers hoe ze toegang moeten krijgen tot de service? Als u bijvoorbeeld een queryreeks gebruikt om tenants te identificeren, moet een centrale landingspagina dan gebruikers om leiden naar de juiste tenant door de queryreeks toe te voegen?
• Hebt u een centraal toegangspunt, zoals een landingspagina of aanmeldingspagina, die door alle tenants wordt gebruikt? Als u dit doet, hoe identificeren gebruikers dan de tenant die ze nodig hebben?
• Biedt uw toepassing API's? Is uw webtoepassing bijvoorbeeld een toepassing met één pagina (SPA) of een mobiele toepassing met een API-back-end? Als dat het zo is, kunt u mogelijk een API-gateway of omgekeerde proxy gebruiken om tenanttoewijzing uit te voeren.

Tokenclaims

Veel toepassingen maken gebruik van op claims gebaseerde verificatie- en autorisatieprotocollen, zoals OAuth 2.0 of SAML. Deze protocollen bieden autorisatietokens aan de client. Een token bevat een set claims. Dit zijn stukjes informatie over de clienttoepassing of gebruiker. Claims kunnen worden gebruikt voor het communiceren van informatie zoals het e-mailadres van een gebruiker. Uw systeem kan vervolgens het e-mailadres van de gebruiker opnemen, de toewijzing van gebruiker naar tenant op zoeken en de aanvraag vervolgens doorsturen naar de juiste fysieke tenantinfrastructuur. Of u kunt zelfs de tenanttoewijzing opnemen in uw identiteitssysteem en een tenant-id-claim toevoegen aan het token.

Als u claims gebruikt om aanvragen toe te wijs aan tenants, moet u rekening houden met de volgende vragen:

• Gebruikt u een claim om een tenant te identificeren? Welke claim gebruikt u?
• Kan een gebruiker lid zijn van meerdere tenants? Als dit mogelijk is, hoe selecteren gebruikers dan de tenants met wie ze willen werken?
• Is er een centraal verificatie- en autorisatiesysteem voor alle tenants? Zo niet, hoe zorgt u ervoor dat alle tokeninstanties consistente tokens en claims uitgeven?

API-sleutels

Veel toepassingen maken API's mogelijk. Deze kunnen zijn voor intern gebruik binnen uw organisatie of voor extern gebruik door partners of klanten. Een veelgebruikte verificatiemethode voor API's is het gebruik van een API-sleutel. API-sleutels worden bij elke aanvraag geleverd en kunnen worden gebruikt om de tenant op te zoeken.

API-sleutels kunnen op verschillende manieren worden gegenereerd. Een veelgebruikte benadering is het genereren van een cryptografisch willekeurige waarde en het opslaan ervan in een opzoektabel, naast de tenant-id. Wanneer een aanvraag wordt ontvangen, vindt uw systeem de API-sleutel in de opzoektabel en wordt deze vervolgens aan een tenant-id gevonden. Een andere benadering is het maken van een zinvolle tekenreeks met daarin een tenant-id, waarna u de sleutel digitaal ondertekent met behulp van een benadering zoals HMAC. Wanneer u elke aanvraag verwerkt, controleert u de handtekening en extraheert u vervolgens de tenant-id.

Denk na over de volgende vragen:

• Hoe genereert en geeft u API-sleutels uit?
• Hoe ontvangen uw API-clients de API-sleutel veilig en slaan ze deze op?
• Wilt u dat uw API-sleutels na een bepaalde periode verlopen? Hoe roteert u de API-sleutels van uw clients zonder downtime te veroorzaken?
• Biedt alleen het vertrouwen op door de klant rollende API-sleutels een voldoende beveiligingsniveau voor uw API's?

Clientcertificaten

Verificatie van clientcertificaten, ook wel wederzijdse TLS (mTLS) genoemd, wordt vaak gebruikt voor service-naar-service-communicatie. Clientcertificaten bieden een veilige manier om clients te verifiëren. Clientcertificaten bieden, net als tokens en claims, kenmerken die kunnen worden gebruikt om de tenant te bepalen. Het onderwerp van het certificaat kan bijvoorbeeld het e-mailadres van de gebruiker bevatten, dat kan worden gebruikt om de tenant op te zoeken.

Houd bij het plannen van het gebruik van clientcertificaten voor tenanttoewijzing rekening met het volgende:

• Hoe gaat u veilig de clientcertificaten uitgeven en vernieuwen die door uw service worden vertrouwd? Clientcertificaten kunnen complex zijn om mee te werken, omdat ze een speciale infrastructuur nodig hebben om certificaten te beheren en uit te geven.
• Worden clientcertificaten alleen gebruikt voor initiële aanmeldingsaanvragen of gekoppeld aan alle aanvragen voor uw service?
• Wordt het proces van het uitgeven en beheren van certificaten onbeheerbaar wanneer u een groot aantal clients hebt?
• Hoe implementeert u de toewijzing tussen het clientcertificaat en de tenant?

Omgekeerde proxies

Een omgekeerde proxy, ook wel een toepassingsproxy genoemd, kan worden gebruikt om HTTP-aanvragen te routeer. Een omgekeerde proxy accepteert een aanvraag van een eindpunt voor ingress en kan de aanvraag doorsturen naar een van de vele back-end-eindpunten. Omgekeerde proxies zijn handig voor multitenant-toepassingen, omdat ze de toewijzing tussen een deel van de aanvraaggegevens kunnen uitvoeren, door de taak van uw toepassingsinfrastructuur te offloaden.

Veel omgekeerde proxies kunnen de eigenschappen van een aanvraag gebruiken om een beslissing te nemen over tenantroutering. Ze kunnen de doeldomeinnaam, het URL-pad, de queryreeks, HTTP-headers en zelfs claims binnen tokens inspecteren.

De volgende veelvoorkomende omgekeerde proxies worden in Azure gebruikt:

• Azure Front Door is een wereldwijde load balancer en webtoepassingsfirewall. Het maakt gebruik van het Wereldwijde Edge-netwerk van Microsoft om snelle, veilige en zeer schaalbare webtoepassingen te maken.
• Azure Application Gateway is een beheerd webverkeer dat load balancer u implementeert in dezelfde fysieke regio als uw back-service.
• Azure API Management is geoptimaliseerd voor API-verkeer.
• Commerciële en opensource-technologieën (die u zelf host) omvatten nginx, Traefik en HAProxy.

Validatie aanvragen

Het is belangrijk dat uw toepassing controleert of alle aanvragen die worden ontvangen, zijn geautoriseerd voor de tenant. Als uw toepassing bijvoorbeeld een aangepaste domeinnaam gebruikt om aanvragen toe te kennen aan de tenant, moet uw toepassing nog steeds controleren of elke aanvraag die door de toepassing wordt ontvangen, is geautoriseerd voor die tenant. Hoewel de aanvraag een domeinnaam of andere tenant-id bevat, betekent dit niet dat u automatisch toegang moet verlenen. Wanneer u OAuth 2.0 gebruikt, voert u de validatie uit door de doelgroep en bereikclaims te inspecteren.

Bij het implementeren van aanvraagvalidatie moet u rekening houden met het volgende:

• Hoe gaat u alle aanvragen voor uw toepassing autoreren? U moet aanvragen autor toestemming geven, ongeacht de benadering die u gebruikt om ze toe te staan aan de fysieke infrastructuur.
• Gebruik vertrouwde en veelgebruikte verificatie- en autorisatie-frameworks en middleware, in plaats van alle validatielogica zelf te implementeren. Maak bijvoorbeeld geen validatielogica voor tokenhandtekeningen of cryptografiebibliotheken voor clientcertificaten. Gebruik in plaats daarvan functies van uw toepassingsplatform (of bekende vertrouwde pakketten) die zijn gevalideerd en getest.

Prestaties

Tenanttoewijzingslogica wordt waarschijnlijk uitgevoerd bij elke aanvraag naar uw toepassing. Bedenk hoe goed het tenanttoewijzingsproces wordt geschaald naarmate uw oplossing groeit. Als u bijvoorbeeld een query uitvoert op een databasetabel als onderdeel van uw tenanttoewijzing, ondersteunt de database dan een grote hoeveelheid belasting? Als voor uw tenanttoewijzing een token moet worden ontsleuteld, worden de rekenvereisten dan in de tijd te hoog? Als uw verkeer redelijk beperkt is, heeft dit waarschijnlijk geen invloed op uw algehele prestaties. Wanneer u echter een grootschalige toepassing hebt, kan de overhead die bij deze toewijzing komt kijken, aanzienlijk worden.

Sessieaffiniteit

Een benadering voor het verminderen van de overhead voor prestaties van tenanttoewijzingslogica is het gebruik van sessie-affiniteit. In plaats van de toewijzing voor elke aanvraag uit te voeren, kunt u overwegen om de informatie alleen bij de eerste aanvraag voor elke sessie te berekenen. Uw toepassing levert vervolgens een sessiecookie aan de client die vervolgens aan uw service kan worden doorgegeven, met alle volgende clientaanvragen binnen die sessie.

Denk na over de volgende vragen:

• Kunt u sessie-affiniteit gebruiken om de overhead van toewijzingsaanvragen aan tenants te verminderen?
• Welke services gebruikt u om aanvragen naar de fysieke implementaties voor elke tenant te routeer? Ondersteunen deze services sessie-affiniteit op basis van cookies?

Tenantmigratie

Tenants moeten vaak worden verplaatst naar een nieuwe infrastructuur als onderdeel van de levenscyclus van de tenant. Wanneer een tenant wordt verplaatst naar een nieuwe implementatie, kunnen de HTTP-eindpunten die ze openen, worden gewijzigd. Als dit gebeurt, moet u er rekening mee houden dat uw tenanttoewijzingsproces moet worden bijgewerkt. Mogelijk moet u rekening houden met het volgende:

• Als uw toepassing domeinnamen gebruikt voor toewijzingsaanvragen, is er op het moment van de migratie mogelijk ook een DNS-wijziging vereist. Het kan even duren voor de DNS-wijziging is doorgegeven aan clients, afhankelijk van de time-to-live van de DNS-vermeldingen in uw DNS-service.
• Als tijdens het migratieproces de adressen van eindpunten tijdens het migratieproces worden gewijzigd, kunt u aanvragen voor de tenant tijdelijk omleiden naar een onderhoudspagina die automatisch wordt vernieuwd.

Volgende stappen

Meer informatie over overwegingen bij het werken met domeinnamen in een multitenant-toepassing.