While AzureAD is not new, the new and exciting B2C brings new possibilities to the game. Centrally managing your customers and their profiles, abstracting away AzureAD stuff while still relying in its power and proven capabilities, gives you a flexibility that was not really there before.
With Sitecore being built to be easily extensible and extremely customizable, an integration between both systems was inevitable. Today, let’s talk about such integration by presenting a scenario, making a few assumptions, and finally deciding on an approach (Hint: it’s oAuth2 stuff).
By the way, B2C is still in preview, so some changes may apply once it comes out full blown. Also, if you want code, you’d better stay tuned for part 2!
AwesomeCompany Ltd. is a retailer offering all kinds of products. It’s a successful company, and as such it decided to embrace the Digital world by leveraging Sitecore’s capabilities for tailoring the user experience and really get to know the customers. Furthermore, the company wants to take advantage of multiple channels, so the customer profiles must live in a place websites, mobile apps and a multitude of other channels can access in an easy, centralized manner.
The platform of choice then it’s Azure AD.
For this scenario, we’ll assume that:
- Customers are not going to access the Sitecore backend, therefore they don’t need to be assigned specific permissions or roles.
- For all intent and purposes, a customer will just be an external user with extranet\anonymous permissions to Sitecore, and the application itself (website, app, etc) will validate access to certain portions of itself (for instance, the edit profile page, or an orders history page).
- Some applications will need to communicate with other applications for gathering data about the customer. In these situations, the authenticated customer should not be asked to re-authenticate, as it would break the flow of the experience. Therefore, there should be a way to send a customer authentication token to other applications, so they can validate it without prompting the user again and again.
- There’s going to be heavy use of Sitecore’s personalization and experience capabilities, therefore we need to ensure not to introduce anything that can potentially lead to dirty workarounds in the future.
The possible approaches
For this scenario, we considered many potential solutions:
- It’s easy to integrate
- it works seamlessly with Sitecore
- it’s a one-time setup
- there’s good official documentation
- Covers assumtion #4 with no extra effort
- It makes assumtion #2 unnecessary as this is almost instantaneous using Sitecore’s OOB functonality.
- There are guides on how to use it with AzureAD. For instance, here’s one by Jonathan Vardy. (It’s for authenticating content authors but it can be easily done for visitors too. Heck, in fact, go and follow that blog, I know Jonathan from working in the same company, and I have personally worked with, and shared an asado, with the other blog’s author, Derk Hudepol. They both know their stuff.) </end free promotion>
- It does not really cover assumption #3 without additional work.
- It gives us things that we don’t need, as per assumption #1.
- Can cover assumption #3.
- It can be tweaked to cover #2.
- It’s tested by many, so we are fairly sure it covers #4 too.
- Some modifications are needed to make it work with Sitecore 8+, which can lead to us inadvertedly introducing issues.
- It really gives us more than we need for this particular scenario.
- Doesn’t *really* fit our needs without extra work.
- It solves some issues with the ADFS module approach.
- It can give us assumption #3 with ease.
- It can be tailored to cover #2.
- As with the ADFS approach, this one gives us way more than we need.
- This one also requires extra work to fit exactly what we need.
…and many more. In fact, we invested a lot of time researching and thinking about authentication and putting it into the perspective of AwesomeCompany’s needs.
Additionally, since the management of roles, permissions and such AD stuff is an unnecessary complexity for this scenario, we to use B2C to simplify customer management. And of course, being in preview, there are not many examples out there of using it specifically with Sitecore.
Therefore, after much thought, I made a decision – We were going to build our own way of authenticating B2C customers into Sitecore. It makes sense – since all of the alternatives we considered *would* require extra work, why not start fresh and build a solution that covers all assumptions and does not add extra complexity where it’s not needed.
The chosen one
Our solution, then, will:
Rely on oAuth2 so we can just pass tokens around – when requesting a resource from another application, it will receive the token and call use B2C capabilities to validate it.
- Make use of (of course) virtual users – that is, Sitecore’s own capabilities to create a non-persistent user on the fly, which is of course with Sitecore’s full arsenal of Experience awesomeness.
- NOT rely on Owin – Owin is fantastic but it would really add a complexity that we don’t need, and we are not going to use its full potential anyway.
- Use Sitecore’s way of tapping into things (i.e. pipeline processors) as we always have.
- We are going to use OpenID, which works on top of oAuth and it’s just easy and standard.
The result was a very, very simple way of handling this with a few lines of code, fewer than we initially thought.
So, you really want to know how it ends? Maybe see some code? You’ll have to come back and see part 2 of this mini-series.
Cliffhanger much? Go blame The Walking Dead 😛