Azure B2C: de wereld van custom policies

in ,

Onlangs werd ik gevraagd voor een klant om een ontzettend leuke Azure B2C opdracht uit te voeren.
Nieuwe technologie, veel uit te zoeken, nieuwe uitdaging….kortom: GAAF!

Gezien de razendsnelle ontwikkelingen van Microsoft op het gebied van o.a. Azure AD zou je denken dat ook Azure B2C redelijk makkelijk te implementeren is. En ja…daar sta je dan, na de documentatie al vrij snel te hebben doorgenomen. De portal en standaard policies gebruiken voor geavanceerde scenario’s? Vergeet het maar! Welkom in de wereld van custom policies!

Deep-dive custom policies

Tijdens de uitvoering van het project liepen wij gelijk tegen de grenzen aan wat er met betrekking tot Azure B2C Custom Policies is gedocumenteerd in het Identity Experience Framework (Officiële Azure B2C documentatie).Ok…hoe begin je dan? Gezond verstand gebruiken en terug gaan naar de basis: beginnen om alle autenticatie workflows te beschrijven. Dat vormt de basis om vervolgens alle user journeys stap voor stap te crëeren. Over het algemeen dient bijna elke authenticatie flow afgedekt te worden. Indien gebruikers van meerdere applicaties gebruik dienen te maken dan ontkom je niet aan zelfontwikkeling en dus een helder beeld vooraf:

”Begin nooit meteen headfirst aan Azure B2C Custom Policies zonder eerst helder alle authenticatie flows & customer journeys te hebben gedefinieerd”

Keuzes, keuzes, keuzes…

In Azure B2C heb je allerlei keuzemogelijkheden, zoals bijvoorbeeld:

  • Wel of geen Multi-Factor Authenticate (MFA) afdwingen?

  • Dienen Terms & Conditions getekend te worden & dient de ondertekening ook gecontroleerd te worden?

  • Wat voor een sign-up flow en sign-in flow wil ik?

  • Dienen de workflows te werken met meerdere applicaties? (niet native ondersteund in Azure B2C!)

  • Wat als het telefoonnummer gewijzigd dient te worden?

  • Moet er in de background API’s worden aangeroepen?

Hoe werkt dat in de wereld van Azure B2C?

Sign-up flow: Geef bijvoorbeeld je contractnummer & postcode - In de backend applicatie wordt er dan gecontroleerd of die combinatie klopt en jij een bestaande klant bent. Als dat gevalideerd is dan gaan we verder met de flow voor additionele gegevens zoals displayname en wachtwoord.

Sign-in flow - Ik log in met hiervoor aangemaakte credentials - ik krijg een tweede authenticatie verzoek (MFA).

Voorbeeld

Ok, laten we een duidelijk voorbeeld geven van een scenario waarbij wij uitgebreid aan de slag zijn gegaan met Custom Policies. Het scenario? Verander Telefoonnummer.

Het was van belang dat de klant via self-service, tijdens bijvoorbeeld de sign-in flow, het telefoonnummer kon wijzigen. In Azure B2C kan alleen een (IT)administrator dit normaal gesproken. Hoe hebben we dat opgelost?

De standaard code voor MFA leest een aantal dingen uit Active Directory. Als je daarin staat dan ben je dus aangemeld voor MFA en zul je altijd worden verzocht om je als klant via MFA te authenticeren. Hoe daar omheen denk je wellicht? Wat als we dat veld niet uitlezen of dat veld weggooien in de custom policy, wat dan? Dan heb je geen telefoonnummer, dus ben je niet aangemeld en kun je opnieuw het telefoonnummer vragen. Voor wijzigen van het telefoonnummer kun je dus simpelweg het attribuut niet uitlezen zodat het Framework denkt dat je niet aangemeld bent voor MFA. Dit is iets wat we zelf hebben ontdekt waarvan Microsoft aangaf dat het (nog) niet bestaat.

Limieten van Azure B2C?

De normale policies bieden normale flows met normale attributen, je kunt extensies toevoegen, pagina’s customizen. Je kunt heel veel met Azure B2C zolang je je maar verdiept in Custom Policies en je creatief bent. Dus in die zin kun je niet echt spreken van limieten.

Waar het Identity Experience Framework een kans laat liggen is de focus op open standaarden zoals OpenID Connect of OAuth. Open standaarden zijn uitstekend, echter als je vanuit de policies zelf API’s gaat aanroepen, dan wordt er geen OAuth grant type ondersteund. Steeds meer API’s worden tegenwoordig inclusief OAuth omgeving aangeboden waarbij je bijvoorbeeld een acces token nodig hebt om die API aan te roepen. Azure B2C mist dat helaas. Simpel gezegd: Je kunt niet bij een autorisatieserver een access token ophalen en dat meenemen in een aanroepen naar een API.

Tevens is Azure B2C erg gericht op het ondersteunen van één applicatie. De focus ligt op authenticatie en niet op autorisatie. Echter zijn er genoeg bedrijven die meerdere applicaties hebben en deze toegankelijk willen maken voor groepen eindgebruikers. Wij hebben dit opgelost door zelf de logica te bouwen op basis van de mogelijkheden die het werken met custom policies biedt. Door het werken met groepen (gebruiker voor applicatie X hoeft niet per se toegang te krijgen tot applicatie Y), het definiëren van autorisatiemodellen, verwerken van controles op autorisaties & error-handling hebben wij het voor elkaar gekregen om een uitgebreide set aan workflows te implementeren. Eindgebruikers kunnen op basis van groepen en custom attributen gebruik maken van één of meerdere applicaties en de controles op die autorisaties worden netjes uitgevoerd. Ondanks dat het natuurlijk fantastisch is om te bouwen zou het een groot pluspunt zijn als dit standaard beschikbaar komt in Azure B2C.

Is Azure B2C iets voor mijn organsatie?

Azure B2C is een fantastische mogelijkheid met vele opties, echter is het wel van belang om jezelf eerst de volgende vragen te stellen:

  • Heb ik eindgebruikers die via web inloggen en waarbij social providers (Facebook, Google, etc.) makkelijk ondersteund moeten kunnen worden zonder gedoe met usernames & wachtwoorden?

  • Moeten eindgebruikers via Multi-Factor Authenticatie inloggen?

  • Wil ik centraal consent kunnen controleren?

  • Maakt u al gebruik van Azure B2B en wilt u deze partners ook toegang verlenen via hun employeeID?

Als het antwoord op één of meerdere van deze vragen positief is, dan kan Azure B2C zeker iets voor u zijn. Nieuwsgierig en wil je meer weten? Neem dan gerust contact met ons op!