Using Okta as Federated Authentication for Sitecore v10.x
Introduction
I have implemented the OKTA integration into Sitecore 10 solution last year, and would like to share a few learnings that I got from it.
Firstly, I would like to shout out to Meng Han Li on the following 2blog posts, which really help me kick start my integration.
His blog posts showcased how to leverage various supported Okta methods / endpoints (Identity Token, Okta Profile APIs) with Sitecore’s OpenID Connect (OIDC), which in turn would create Sitecore virtual users.
I also highly recommend reading Sitecore’s documentation thoroughly, and constantly referring back to it during your development.
Customer Identity Access Management (CIAM)
Customer Identity is a very important part of our organisation. The Sitecore web site is only one of the many consuming application of OKTA in the organisation. There is very strict governance on the attributes of information allowed to be synced into Okta from the CRM.
To setup a Sitecore virtual user, the various attributes of the user may come from many different internally hosted APIs, OKTA Identity Token, OKTA JWT Access Token. Gathering all the information of a user during the login process can unlock the potential use cases for personalisation to be implemented on Sitecore Server Side Rendering, or with Composable DXP using Over The Top (OTT) Personalisation, or even Personalised Search.
Populating Claims for Sitecore Virtual User
A Sitecore virtual user can be created with a lot of attributes populated without any code at all, providing that the Claims are available so that they can be mapped in just a normal Sitecore configuration file.
The trick, is to push in all the custom logic that is required, and make those available in the list of Claims. In Meng Han’s example, you can see that he is putting this logic in the Okta.AuthorizationCodeReceived Pipeline. The really important part, is that the claims are added in each individual Pipeline Processor, with args.Notification.AuthenticationTicket.Identity.AddClaims(customClaims). In my implementation, I have implemented multiple pipeline processors to populate the final claims. I also need to save the JWT Access Token from Okta into Redis, so that it can be used for some of the internal API Access, which requires Bearer Tokens to be passed into other HTTP Rest API endpoint’s Authorization header. Adding another pipeline processor in the same pipeline is a logical place to perform such task.
External User Builder
Quite a few people have asked this question on Sitecore’s Slack channel on how to setup the externalUserBuilder properly. I suggest reading the official documentation properly again, where the identityProvidersPerSites setting needs to be setup properly. In my implementation, I have decided to totally do away with setting up end user Federated authentication into the ContentManagement role altogether, and patched that away to avoid any further confusions. I personally think that even a local development environment should emulate the production environment as close as possible with a XM Scaled setup.
Final Word of Advice
All the Federated Authentication examples you can find in Sitecore StackExchange, various blog posts would have most common implementation examples. The key, is to read the official Sitecore documentation thoroughly, and refer back to it all the time.
