Tolerantie door best practices voor ontwikkelaars

  • Artikel

In dit artikel delen we enkele dingen die we hebben geleerd uit onze ervaring met het werken met grote klanten. U kunt deze aanbevelingen overwegen voor het ontwerp en de implementatie van uw services.

Image shows developer experience components

MSAL (Microsoft Authentication Library ) gebruiken

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

Ontwikkelaars moeten de nieuwste releases van MSAL gebruiken en up-to-date blijven. Kijk hoe u de tolerantie van verificatie en autorisatie in uw toepassingen kunt vergroten. Vermijd waar mogelijk het implementeren van uw eigen verificatiestack, en gebruik gerenommeerde bibliotheken.

Lees- en schrijfbewerkingen voor mappen optimaliseren

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

Lees- en schrijfbewerkingen voor mappen optimaliseren

  • Vermijd schrijffuncties naar de map bij aanmelding: voer nooit een schrijfbewerking uit bij aanmelding zonder een voorwaarde (indien-component) in uw aangepaste beleid. Eén gebruiksvoorbeeld waarvoor een schrijfbewerking voor een aanmelding is vereist, is Just-In-Time-migratie van gebruikerswachtwoorden. Vermijd scenario's waarbij voor elke aanmelding een schrijfbewerking is vereist. Voorwaarden in een gebruikerstraject zien er als volgt uit:

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

  • Meer informatie over beperking: de map implementeert regels voor beperkingsregels op toepassings- en tenantniveau. Daarnaast zijn er frequentielimieten voor Read/GET-, Write/POST-, Update/PUT- en Delete/DELETE-bewerkingen, en elke bewerking heeft andere limieten.

    • Een schrijfbewerking op het moment van aanmelding valt onder POST voor nieuwe gebruikers of PUT voor bestaande gebruikers.
    • Aangepast beleid waarmee een gebruiker wordt gemaakt of bijgewerkt bij elke aanmelding, kan mogelijk 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 beperken.
    • Schat piekbelasting om de snelheid van mapschrijfbewerkingen te voorspellen en beperking te voorkomen. Schattingen voor pieken in het verkeer moeten schattingen bevatten voor acties zoals registreren, aanmelden en MFA (Multi-Factor Authentication). Zorg ervoor dat u zowel het Azure AD B2C-systeem als de toepassing test voor piekverkeer. Het is mogelijk dat Azure AD B2C de belasting kan 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, kunt u de limieten voor toepassingen en tenants controleren om de benodigde tijd te berekenen voor het voltooien van de migratie van gebruikers. 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. Dit moet nog steeds onder de drempelwaarde per tenant blijven.
    • 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 u geen beperking op tenantniveau veroorzaakt en dat er resources worden verhongerd voor uw livetoepassing. Zie de Microsoft Graph-beperkingsrichtlijnen voor meer informatie.
    • Gebruik een voorbeeld van een belastingstest om registratie en aanmelding te simuleren.
    • Meer informatie over azure Active Directory B2C-servicelimieten en -beperkingen.

Levensduur van tokens verlengen

In het onwaarschijnlijke geval dat de Azure AD B2C-verificatieservice geen nieuwe registraties en aanmeldingen kan voltooien, kunt u nog steeds risicobeperking bieden voor gebruikers die zijn aangemeld. Met configuratie kunt u toestaan dat een gebruiker die al is aangemeld, de toepassing blijft gebruiken zonder enige waargenomen onderbreking, totdat de gebruiker zich afmeldt bij de toepassing of een time-out voor de sessie optreedt vanwege inactiviteit.

Uw zakelijke vereisten en de gewenste eindgebruikerservaring bepalen de frequentie van tokenvernieuwing voor zowel webtoepassingen als SPA's (toepassingen met één pagina).

Levensduur van tokens verlengen

  • Webtoepassingen: voor webtoepassingen waarbij het verificatietoken aan het begin van de aanmelding wordt gevalideerd, is de toepassing afhankelijk van de sessiecookie om de geldigheid van de sessie te blijven verlengen. Zorg ervoor dat gebruikers aangemeld blijven door doorlopende sessietijden te implementeren, waarbij sessies continu worden verlengd op basis van gebruikersactiviteit. Als er sprake is van een storing in de uitgifte van tokens op lange termijn, kunnen deze sessietijden verder worden verhoogd als een eenmalige configuratie van de toepassing. Houd de levensduur van de sessie op het maximum dat is toegestaan.
  • SPA's: een SPA kan afhankelijk zijn van toegangstokens die de API's aanroepen. Een SPA maakt gewoonlijk gebruik van de impliciete stroom die niet resulteert 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 nog steeds een actieve sessie met Azure AD B2C heeft. Voor SPA's zijn er enkele opties beschikbaar waarmee de gebruiker de toepassing kan blijven gebruiken.
    • Breid de geldigheidsduur van het toegangstoken uit om te voldoen aan uw zakelijke vereisten.
    • Bouw uw toepassing om een API-gateway te gebruiken als verificatieproxy. In deze configuratie wordt de SPA geladen zonder verificatie, en worden de API-aanroepen gedaan bij de API-gateway. De API-gateway verzendt de gebruiker via een aanmeldingsproces met behulp van een autorisatiecodetoekenning op basis van beleid, en verifieert de gebruiker. Vervolgens wordt de verificatiesessie tussen de API-gateway en de client onderhouden met behulp van een verificatiecooky. De API-gateway services de API's met behulp van het token dat wordt verkregen door de API-gateway (of een andere directe verificatiemethode, zoals certificaten, clientreferenties of API-sleutels).
    • Migreer uw SPA van impliciete toekenning naar de stroom voor autorisatietoekenning met ondersteuning voor PKCE (Proof Key for Code Exchange) en CORS (Cross-origin Resource Sharing). Migreer uw toepassing van MSAL.js 1.x naar MSAL.js 2.x, om de tolerantie van webtoepassingen te realiseren.
    • Voor mobiele toepassingen is het raadzaam om de levensduur van zowel vernieuwingstokens als toegangstokens te verlengen.
  • Back-end- of microservicetoepassingen: omdat back-endtoepassingen (daemon) niet-interactief zijn en zich niet in een gebruikerscontext bevinden, wordt het vooruitzicht van tokendiefstal aanzienlijk verminderd. Het wordt aanbevolen om een evenwicht te vinden tussen beveiliging en levensduur, en een lange tokenlevensduur in te stellen.

Eenmalige aanmelding configureren

Met Eenmalige aanmelding (SSO) melden gebruikers zich eenmaal aan met een enkel account, en krijgen ze toegang tot meerdere toepassingen. Het kan gaan om een webtoepassing, een mobiele toepassing of een SPA (toepassing met één pagina), ongeacht het platform of de domeinnaam. Wanneer de gebruiker zich in eerste instantie aanmeldt bij een toepassing, blijft Azure AD B2C een sessie op basis van cookies behouden.

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

Eenmalige aanmelding configureren

Configureer eenmalige aanmelding tenantbreed (standaard), zodat meerdere toepassingen en gebruikersstromen in de tenant dezelfde gebruikerssessie kunnen delen. Tenantbrede configuratie biedt de meeste tolerantie voor nieuwe verificatie.

Veilige implementatiemethoden

De meest voorkomende verstoringen van de service zijn de code- en configuratiewijzigingen. Acceptatie van CICD-processen (Continuous Integration and Continuous Delivery) helpt bij snelle implementatie op grote schaal, en vermindert menselijke fouten tijdens het testen en implementeren in productie. Gebruik CICD voor foutreductie, efficiëntie en consistentie. Azure Pipelines is een voorbeeld van CICD.

Beveiligen tegen bots

Bescherm uw toepassingen tegen bekende beveiligingsproblemen, zoals DDoS-aanvallen (Distributed Denial of Service), SQL-injecties, uitvoeren van scripts op meerdere sites, uitvoeren van externe code en nog veel meer, zoals beschreven in OWASP Top 10. De implementatie van een WAF (Web Application Firewall) kan bescherming bieden tegen veelvoorkomende aanvallen en beveiligingsproblemen.

Geheimen rouleren

Azure AD B2C gebruikt geheimen voor toepassingen, API's, beleidsregels en versleuteling. De geheimen beveiligen verificatie, externe interacties en opslag. Het NIST (National Institute of Standards and Technology) roept de tijdsduur aan waarin een specifieke sleutel is geautoriseerd voor gebruik door legitieme entiteiten: een cryptoperiode. Kies de juiste lengte voor de cryptoperiode om te voldoen aan de behoeften van uw bedrijf. Ontwikkelaars moeten de vervaldatum handmatig instellen en geheimen ruim vóór de vervaldatum roteren.

Geheimrotatie 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 roteren van referenties.
  • Maak een inventarisatie van alle sleutels en certificaten die zijn geconfigureerd in Azure AD B2C. Deze lijst bevat waarschijnlijk sleutels die worden gebruikt in aangepast beleid, API's, ondertekenings-id-tokens en certificaten voor SAML.
  • Roteer met behulp van CICD geheimen die binnen twee maanden na het verwachte piekseizoen verlopen. De aanbevolen maximale cryptoperiode voor persoonlijke sleutels die aan een certificaat zijn gekoppeld, is één jaar.
  • Bewaak en roteer de API-toegangsreferenties, zoals wachtwoorden en certificaten, proactief.

REST-API's testen

In de context van tolerantie moet het testen van REST API's verificatie omvatten van: HTTP-codes, nettolading van reacties, headers en prestaties. Testen moet niet alleen gemakkelijke padtests bevatten, maar er moet ook worden gecontroleerd of de API probleemscenario's soepel verwerkt.

API's testen

We raden aan dat uw testplan uitgebreide API-tests bevat. Als u van plan bent een aanstaande piek te plannen vanwege een aanbieding of vakantieverkeer, moet u de schattingen voor belastingtests herzien. Voer belastingtests van uw API's en CDN (Content Delivery Network) uit in een ontwikkelomgeving en niet in productie.

Volgende stappen