Welcome to the Azure AD B2C post series!
This is the first post of the series and it is ment to shed some light on what to expect from working with custom policies and to show what I did and what worked for me. I will not delve into definitions of what a B2C is, what Azure AD and Azure AD B2C are as there are lots of more competent people who have already written on that subject. What I will try to explain however are some chosen concepts which, if not clarified, would make posts seem incomplete, disconnected from reality and useful only for a handful of professionals already having experience in the subject.
So, having said that, here we go.
Do I need custom policies?
No, probably not. As long as you’re OK with what you can achieve in policy configuration by clicking around in Azure Portal. If you, however, want to achieve more than is given out of the box, then you probably need to get your hands a bit dirty.
I don’t want to discourage anyone, on the contrary. I consider Identity Experience Framework an extremely interesting, powerful and extensible set of features which can do wonders. However, even Microsoft issues a visible note in the docs saying:
Custom policies are designed primarily to address complex scenarios. For most scenarios, we recommend that you use Azure Active Directory B2C built-in policies. Built-in policies are easier to set up for your configuration.
They don’t lie. You can do complex scenarios and build-in policies are easier.
In case of doubt they also put an information in Azure Portal when you open Identity Experience Framework blade.
This one lies a bit – I’m not an identity pro and I’m still doing it 😉
Technically, as my colleague said- “here be dragons” – and we will meet some of them on the way through the series.
Jokes aside, if you have already tried achieving your goals with build-in policies and know they don’t meet your requirements you can start thinking about custom ones.
How do I begin work on custom policies?
There are several ideas that can be applied.
Building a policy from scratch
Definitely an ambitious approach but in my opinion on the verge of being suicidal. Custom policies, as already mentioned, are complex. There are tons of things you can break there and, well, no local debugging or any real debugging (like with code) for that matter, so troubleshooting can be painful and time consuming.
– you learn a lot, like a lot…
– …but in an extremely painful way
In my opinion – just don’t.
Starting with some downloaded example
There are examples of custom policies scenarios that can be found on the Internet, mainly on Microsoft-run GitHub accounts (no joke intended this time ;)). Some of them are really nice but, like with most examples, they usually don’t fit your requirements as you wished them to. There are things to modify, add and possibly remove.
Additionally, an example from the Internet has an important con – it is a snapshot of functionalities in a certain point in time. Microsoft adds and updates features affecting policies and you can be missing some nice, ready to use stuff when using an outdated example.
– starting with a ready to go policy (or close to that)
– “reverse engineering” samples can help to understand things
– examples can require extensive modifications anyway
– outdated examples miss all the new features
All in all this is a perfectly valid option although I choose to do it in a different way.
Using an exported build-in policy
You start by creating a build-in policy, configuring it to fit as close as possible to your requirements and taking it further from that point.
This is my choice of action as you don’t waste time looking at examples containing, among interesting stuff, some things you don’t actually need or which you have to implement in a different way.
As a result (after some tweaking) you get a working, build-in-compatible policy which contains features you configured according to your requirements. You can test the policy behavior and then look inside to understand (or at least try to) how things are handled under the hood.
As an additional feat, you can leave the build-in policy in place and periodically repeat the exporting process. This allows you to check if there are any new functionalities and to merge them into your custom policy.
To be fair and honest however, I need to mention that the process of exporting a configured build-in policy and importing it back as a custom one is not a straight-forward task and requires some knowledge and patience. More on that later.
– starting with a ready to go policy (more-less)
– a starting point possibly closest to requirements
– easiest way to merge new features
– proper exporting is not straight-forward
– exported policies still need some work even for just enabling them to be imported back
Despite not ideal I still find this method as the most sensible one and will use it as an example of the beginning process.
Let’s get to it to finish this post with some practical hands-on content.
Exporting a policy
Things may seem easy when you look at the Azure AD B2C interface in Azure Portal. Creating and configuring a build-in policy is a few minutes work and the Download button looks promising, but…
Few things need to be clarified. There’s a recommendation for approaching custom policies to make them “layered” by having a BASE policy file with core functionalities, an EXTension policy file with custom but reusable features and an RP – Relying Party – policy file as the actual policy used by applications.
Layering in this case is “upper” policies adding and overriding values to the “lower” policies. BASE being the lowest and RP being the top one.
Now let’s take a look into documentation:
Built-in policies in Azure AD B2C follow the three-file pattern depicted above, but the developer only sees the Relying Party (RP) file, while the portal makes changes in the background to the EXTensions file.
which means that the policy you export via the Download button is an RP policy file being only a small fraction of what you configured and what you actually need to continue working on your custom solution.
Fortunately there are tools which can help and so with a little help of reverse engineering requests made by portal in the background we can get what we want.
We’ll need a browser with Developer mode and Postman (or any other tool capable of making customized HTTP requests).
- Open the blade with the proper policy with a Download button visible
- Enable Developer mode in browser, switch to Network
- Push the Download button
- Copy Request URL and paste it in Postman
- Copy the token and configure Postman authorization with it
- Now the magic part – change the getBasePolicies query parameter value to true
- Launch the request and here you go, an XML content with policies. Save it as an .xml file.
So we got the policies we wanted (sort of, but no spoilers for now).
You can look inside the file (warning: it’s big) by yourself and try to make any sense of it.
Or you can check the next post which will be about tooling, documentation and resources enabling us to understand custom policies and work on them.
See you soon!