Share via

Tolerantie via best practices voor ontwikkelaars

  • Artikel

In dit artikel kunt u profiteren van onze ervaring met het werken met grote klanten. U kunt deze aanbevelingen overwegen voor het ontwerp en de implementatie van uw services.

Microsoft Authentication Library

Microsoft Authentication Library (MSAL) en de Microsoft Identity Web Authentication Library (Microsoft Identity Web Authentication Library) voor ASP.NET het verkrijgen, beheren, opslaan in de cache en het vernieuwen van de tokens voor toepassingen vereenvoudigen. Deze bibliotheken zijn geoptimaliseerd ter ondersteuning van Microsoft Identity, inclusief functies die de tolerantie van toepassingen verbeteren.

Ontwikkelaars kunnen gebruikmaken van de nieuwste releases van MSAL en up-to-date blijven. Bekijk hoe u de tolerantie van verificatie en autorisatie in uw toepassingen kunt vergroten. Vermijd waar mogelijk het implementeren van uw eigen verificatiestack. Gebruik in plaats daarvan goed gevestigde bibliotheken.

Directory-lees- en schrijfbewerkingen optimaliseren

De Azure AD B2C-adreslijstservice ondersteunt miljarden verificaties per dag, met een hoog aantal leesbewerkingen per seconde. Optimaliseer uw schrijfbewerkingen om afhankelijkheden te minimaliseren en de tolerantie te vergroten.

Maplees- en schrijfbewerkingen optimaliseren

  • Schrijffuncties voorkomen in de directory bij aanmelding: vermijd het uitvoeren van een schrijfbewerking bij aanmelding zonder voorwaarde (if-component) in uw aangepaste beleid. Een use case waarvoor een schrijfbewerking voor een aanmelding is vereist, is just-in-time migratie van gebruikerswachtwoorden. Schrijf niet op elke aanmelding. Voorwaarden in een gebruikerstraject zijn:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Meer informatie over beperking: de directory implementeert regels voor beperking op toepassings- en tenantniveau. Er zijn meer frequentielimieten voor lees-/GET-, schrijf-/POST-, update-/PUT- en delete-bewerkingen. Elke bewerking heeft verschillende limieten.

    • Een schrijfbewerking tijdens aanmelding valt onder een POST voor nieuwe gebruikers of PUT voor huidige gebruikers.
    • Een aangepast beleid waarmee een gebruiker bij elke aanmelding wordt gemaakt of bijgewerkt, kan een PUT- of POST-frequentielimiet op toepassingsniveau bereiken. Dezelfde limieten gelden voor het bijwerken van mapobjecten via Microsoft Entra ID of Microsoft Graph. Bekijk ook de leesbewerkingen om het aantal leesbewerkingen bij elke aanmelding tot het minimum te houden.
    • Maak een schatting van de piekbelasting om de snelheid van directory-schrijfbewerkingen te voorspellen en beperking te voorkomen. Schattingen van piekverkeer moeten schattingen bevatten voor acties zoals registratie, aanmelding en meervoudige verificatie (MFA). Test het Azure AD B2C-systeem en uw toepassing voor piekverkeer. Azure AD B2C kan de belasting verwerken zonder beperking, wanneer uw downstreamtoepassingen of -services dat niet doen.
    • Uw migratietijdlijn begrijpen en plannen. Wanneer u van plan bent om gebruikers te migreren naar Azure AD B2C met behulp van Microsoft Graph, moet u rekening houden met de limieten voor toepassingen en tenants om de tijd te berekenen voor het voltooien van de gebruikersmigratie. Als u de taak of het script voor het maken van gebruikers splitst met behulp van twee toepassingen, kunt u de limiet per toepassing gebruiken. Zorg ervoor dat deze onder de drempelwaarde per tenant blijft.
    • Inzicht in de effecten van uw migratietaak op andere toepassingen. Houd rekening met het liveverkeer dat wordt geleverd door andere relying-toepassingen om ervoor te zorgen dat er geen beperking op tenantniveau en resourceverhongering voor uw livetoepassing is. Zie de richtlijnen voor beperking van Microsoft Graph voor meer informatie.
    • Gebruik een voorbeeld van een belastingstest om registratie en aanmelding te simuleren.
    • Meer informatie over azure AD B2C-servicelimieten en -beperkingen.

Levensduur van tokens

Als de Azure AD B2C-verificatieservice geen nieuwe aanmeldingen en aanmeldingen kan voltooien, biedt u een beperking voor gebruikers die zijn aangemeld. Met configuratie kunnen gebruikers die zijn aangemeld de toepassing zonder onderbreking gebruiken totdat ze zich afmelden bij de toepassing, of wanneer er een time-out optreedt voor de sessie als gevolg van inactiviteit.

Uw zakelijke vereisten en eindgebruikerservaring bepalen de frequentie van het vernieuwen van tokens voor webtoepassingen en TOEPASSINGEN met één pagina (SPA's).

Levensduur van tokens verlengen

  • Webtoepassingen: Voor webtoepassingen waarbij het verificatietoken wordt gevalideerd bij het aanmelden, is de toepassing afhankelijk van de sessiecooky om de geldigheid van de sessie te blijven verlengen. Ervoor zorgen dat gebruikers aangemeld blijven door doorlopende sessietijden te implementeren die worden verlengd op basis van gebruikersactiviteit. Als er sprake is van een storing in de uitgifte van tokens op lange termijn, kunnen deze sessietijden worden verhoogd als een eenmalige configuratie voor de toepassing. Behoud de levensduur van de sessie tot het maximum dat is toegestaan.
  • SPA's: een BEVEILIGD-WACHTWOORDVERIFICATIE is mogelijk afhankelijk van toegangstokens om aanroepen naar de API's te maken. Voor SPA's wordt u aangeraden de autorisatiecodestroom te gebruiken met de PKCE-stroom (Proof Key for Code Exchange) als optie om de gebruiker in staat te stellen de toepassing te blijven gebruiken. Als uw beveiligd-WACHTWOORDVERIFICATIE impliciete stroom gebruikt, kunt u overwegen om te migreren naar autorisatiecodestroom met PKCE. Migreer uw toepassing van MSAL.js 1.x naar MSAL.js 2.x om de tolerantie van webtoepassingen te realiseren. De impliciete stroom resulteert niet in een vernieuwingstoken. De BEVEILIGD-WACHTWOORDVERIFICATIE kan een verborgen iframe sleutel gebruiken om nieuwe tokenaanvragen uit te voeren op het autorisatie-eindpunt als de browser een actieve sessie heeft met Azure AD B2C. Voor SPA's zijn er enkele opties waarmee de gebruiker de toepassing kan blijven gebruiken.
    • De geldigheidsduur van het toegangstoken uitbreiden.
    • Bouw uw toepassing om een API-gateway te gebruiken als verificatieproxy. In deze configuratie wordt de BEVEILIGD-WACHTWOORDVERIFICATIE geladen zonder verificatie en worden de API-aanroepen naar de API-gateway uitgevoerd. De API-gateway verzendt de gebruiker via een aanmeldingsproces met behulp van een autorisatiecodetoekenning, op basis van een beleid en verifieert de gebruiker. De verificatiesessie tussen de API-gateway en de client wordt onderhouden met behulp van een verificatiecooky. De API-gateway services de API's met behulp van het token dat is verkregen door de API-gateway of een andere directe verificatiemethode, zoals certificaten, clientreferenties of API-sleutels.
    • Schakel over naar de aanbevolen optie. Migreer uw BEVEILIGD-WACHTWOORDVERIFICATIE van impliciete toekenning naar autorisatiecodetoekenneringsstroom met ONDERSTEUNING voor Proof Key for Code Exchange (PKCE) en Cross-Origin Resource Sharing (CORS).
    • Voor mobiele toepassingen verlengt u de levensduur van het vernieuwings- en toegangstoken.
  • Back-end- of microservicetoepassingen: Back-endtoepassingen (daemon) zijn niet-interactief en bevinden zich niet in een gebruikerscontext, waardoor het perspectief van tokendiefstal afneemt. Onze aanbeveling is om een evenwicht te vinden tussen beveiliging en levensduur en een lange tokenlevensduur in te stellen.

Eenmalige aanmelding

Met eenmalige aanmelding (SSO) melden gebruikers zich eenmaal aan met een account en krijgen ze toegang tot toepassingen: een web-, mobiele of spa-toepassing (SPA), ongeacht het platform of de domeinnaam. Wanneer de gebruiker zich aanmeldt bij een toepassing, houdt Azure AD B2C een sessie op basis van cookies vast.

Na volgende verificatieaanvragen leest en valideert Azure AD B2C de sessie op basis van cookies en geeft een toegangstoken uit zonder dat de gebruiker wordt gevraagd zich aan te melden. Als eenmalige aanmelding is geconfigureerd met een beperkt bereik voor een beleid of een toepassing, is voor latere toegang tot andere beleidsregels en toepassingen nieuwe verificatie vereist.

Eenmalige aanmelding configureren

Configureer eenmalige aanmelding als tenantbreed (standaard) zodat meerdere toepassingen en gebruikersstromen in uw tenant dezelfde gebruikerssessie kunnen delen. Configuratie voor de hele tenant biedt de meeste tolerantie voor nieuwe verificatie.

Veilige implementatieprocedures

De meest voorkomende serviceonderbrekingen zijn code- en configuratiewijzigingen. Acceptatie van CICD-processen (Continuous Integration and Continuous Delivery) maken implementatie op grote schaal mogelijk en vermindert menselijke fouten tijdens het testen en implementeren. Gebruik CICD voor foutreductie, efficiëntie en consistentie. Azure Pipelines is een voorbeeld van CICD.

Beveiliging tegen bots

Bescherm uw toepassingen tegen bekende beveiligingsproblemen, zoals DDoS-aanvallen (Distributed Denial of Service), SQL-injecties, cross-site scripting, uitvoering van externe code en andere die worden beschreven in OWASP Top-10. Implementeer een WaF (Web Application Firewall) ter bescherming tegen veelvoorkomende aanvallen en beveiligingsproblemen.

Geheimen

Azure AD B2C maakt gebruik van geheimen voor toepassingen, API's, beleid en versleuteling. De geheimen beveiligen verificatie, externe interacties en opslag. Het National Institute of Standards and Technology (NIST) verwijst naar de periode van sleutelautorisatie, gebruikt door legitieme entiteiten, als cryptoperiod. Kies de benodigde lengte van cryptoperiods. Stel de vervaldatum in en roteer geheimen voordat ze verlopen.

Geheime rotatie implementeren

  • Gebruik beheerde identiteiten voor ondersteunde resources om te verifiëren bij elke service die ondersteuning biedt voor Microsoft Entra-verificatie. Wanneer u beheerde identiteiten gebruikt, kunt u resources automatisch beheren, inclusief het rouleren van referenties.
  • Maak een inventarisatie van sleutels en certificaten die zijn geconfigureerd in Azure AD B2C. Deze lijst kan sleutels bevatten die worden gebruikt in aangepast beleid, API's, token voor ondertekenings-id en certificaten voor Security Assertion Markup Language (SAML).
  • Draai met CICD geheimen die binnen twee maanden na het verwachte hoogseizoen verlopen. De aanbevolen maximale cryptoperiode van persoonlijke sleutels die aan een certificaat zijn gekoppeld, is één jaar.
  • Bewaak en roteer de API-toegangsreferenties, zoals wachtwoorden en certificaten.

REST API-tests

Voor tolerantie moeten REST API's worden getest met verificatie van HTTP-codes, nettolading van reacties, headers en prestaties. Gebruik niet alleen gelukkige padtests en controleer of de API probleemscenario's probleemloos verwerkt.

Testplan

Uw testplan wordt aangeraden uitgebreide API-tests te bevatten. Voor pieken als gevolg van een promotie of vakantieverkeer wijzigt u belastingstests met nieuwe schattingen. Voer API-belastingstests en CDN (Content Delivery Network) uit in een ontwikkelomgeving, niet in productie.

Volgende stappen