Tolerante eindgebruikerservaring
De ervaring voor registratie en aanmelding voor eindgebruikers bestaat uit de volgende elementen:
De interfaces waarmee de gebruiker werkt, zoals CSS, HTML en JavaScript
De gebruikersstromen en aangepaste beleidsregels die u maakt, zoals registreren, aanmelden en profiel bewerken
De id-providers (IDP's) voor uw toepassing, zoals gebruikersnaam/wachtwoord van het lokale account, Outlook, Facebook en Google
Kiezen tussen gebruikersstroom en aangepast beleid
Om u te helpen de meest voorkomende identiteitstaken in te stellen, biedt Azure AD B2C ingebouwde, configureerbare gebruikersstromen. U kunt ook uw eigen aangepaste beleidsregels bouwen die u maximale flexibiliteit bieden. Het is echter raadzaam om aangepaste beleidsregels alleen te gebruiken voor complexe scenario's.
Kiezen tussen gebruikersstroom en aangepast beleid
Kies voor ingebouwde gebruikersstromen als aan uw bedrijfsvereisten kan worden voldaan. Omdat deze uitgebreid zijn getest door Microsoft, kunt u de tests die nodig zijn voor het valideren van functionaliteit, prestaties of schaal van deze identiteitsgebruikersstromen op beleidsniveau op een minimum houden. U moet uw toepassingen nog wel testen op functionaliteit, prestaties en schaal.
Als u vanwege uw bedrijfsvereisten aangepast beleid kiest, moet u naast het testen op toepassingsniveau ook testen op beleidsniveau voor functionaliteit, prestaties en schaal.
Zie het artikel met een vergelijking tussen gebruikersstromen en aangepast beleid om u te helpen beslissen.
Meerdere IDP's kiezen
Wanneer u een externe id-provider zoals Facebook gebruikt, moet u een alternatief hebben voor het geval de externe provider niet meer beschikbaar is.
Meerdere IDP's instellen
Neem als onderdeel van het registratieproces van de externe id-provider een geverifieerde identiteitsclaim op, zoals het mobiele nummer of e-mailadres van de gebruiker. Leg de geverifieerde claims vast in het onderliggende Azure AD B2C-directory-exemplaar. Als de externe provider niet beschikbaar is, gaat u naar de geverifieerde identiteitsclaim en gebruikt u het telefoonnummer als alternatieve verificatiemethode. Een andere optie is om de gebruiker een eenmalige wachtwoordcode te sturen, zodat de gebruiker zich kan aanmelden.
Volg deze stappen om alternatieve verificatiepaden te maken:
Configureer uw registratiebeleid om registratie per lokaal account en externe IDP's toe te staan.
Configureer een profielbeleid zodat gebruikers de andere identiteit kunnen koppelen aan hun account nadat ze zich hebben aangemeld.
Informeer gebruikers en sta ze toe om over te schakelen naar een alternatieve IDP tijdens een storing.
Beschikbaarheid van Multi-Factor Authentication
Wanneer u een telefoonservice gebruikt voor Multi-Factor Authentication (MFA), moet u een alternatieve serviceprovider overwegen. De lokale telecom- of telefoonserviceprovider kan onderbrekingen in de service ondervinden.
Een alternatieve MFA kiezen
De Azure AD B2C-service maakt gebruik van een ingebouwde MFA-provider op basis van een telefoon om tijdgebaseerde eenmalige wachtwoordcodes (OTP's) te verstrekken. Het is in de vorm van een spraakoproep en sms-bericht naar het vooraf geregistreerde telefoonnummer van de gebruiker. De volgende alternatieve methoden zijn beschikbaar voor verschillende scenario's:
Wanneer u gebruikersstromen gebruikt, zijn er twee methoden om tolerantie te bouwen:
- Configuratie van gebruikersstroom wijzigen: bij het detecteren van een onderbreking in de op een telefoon gebaseerde OTP-levering, wijzigt u de OTP-leveringsmethode van telefoon naar e-mail en implementeert u de gebruikersstroom opnieuw, waardoor de toepassingen ongewijzigd blijven.
- Toepassingen wijzigen: definieer voor elke identiteitstaak, zoals registreren en aanmelden, twee sets gebruikersstromen. Configureer de eerste set voor het gebruik van op de telefoon gebaseerde OTP en de tweede voor op e-mail gebaseerde OTP. Bij het detecteren van een onderbreking in de op de telefoon gebaseerde OTP-levering, wijzigt en implementeert u de toepassingen om van de eerste set gebruikersstromen naar de tweede over te schakelen, waardoor de gebruikersstromen ongewijzigd blijven.
Wanneer u aangepaste beleidsregels gebruikt, zijn er vier methoden om tolerantie te bouwen. De onderstaande complexiteit is geordend in de volgorde van complexiteit en u moet bijgewerkte beleidsregels opnieuw implementeren.
Gebruikersselectie inschakelen van OTP op basis van een telefoon of op e-mail gebaseerde OTP: stel beide opties beschikbaar voor de gebruikers en stel gebruikers in staat om een van de opties zelf te selecteren. U hoeft geen wijzigingen aan te brengen in het beleid of de toepassingen.
Dynamisch schakelen tussen OTP op basis van telefoon en op e-mail gebaseerde OTP: verzamel tijdens registratie zowel telefoon- als e-mailgegevens. Definieer vooraf aangepast beleid om voorwaardelijk over te schakelen tijdens een telefoononderbreking, van telefoongebaseerde OTP-levering naar OTP-levering op basis van e-mail. U hoeft geen wijzigingen aan te brengen in het beleid of de toepassingen.
Een Authenticator-app gebruiken: werk aangepaste beleidsregels bij om een Authenticator-app te gebruiken. Als uw normale MFA is gebaseerd op telefoon of e-mail, implementeert u uw aangepaste beleidsregels opnieuw om over te schakelen naar gebruik van de Authenticator-app.
Notitie
Gebruikers moeten de integratie van de Authenticator-apps configureren tijdens de registratie.
- Beveiligingsvragen gebruiken: als geen van de bovenstaande methoden van toepassing is, implementeert u beveiligingsvragen als back-up. Stel beveiligingsvragen in voor gebruikers tijdens het onboarden of bewerken van het profiel en sla de antwoorden op in een andere database dan de directory. Deze methode voldoet niet aan de MFA-vereiste van bijvoorbeeld 'iets wat u hebt' maar biedt een secundaire 'iets dat u weet'.
Een Content Delivery Network gebruiken
CDN's (Content Delivery Networks) presteren beter en zijn goedkoper dan blobarchieven voor de opslag van een aangepaste gebruikersstroomgebruikersinterface. De inhoud van webpagina's wordt sneller geleverd vanuit een geografisch gedistribueerd netwerk van maximaal beschikbare servers.
Test regelmatig de beschikbaarheid van uw CDN en de prestaties van inhoudsdistributie via end-to-endscenario's en belastingstests. Als u van plan bent een aanstaande piek te plannen vanwege een aanbieding of vakantieverkeer, herziet u uw schattingen voor belastingtests.