Sitecore Identity Claims Mapping Gotchas

-


Sitecore introduced Identity server in Sitecore 9.1 version to manage authentication and authorization. It allows you to use Federated Authentication to integrate with external identity providers like Azure AD, ADFS and OKTA. I previously worked on integrating Sitecore with ADFS and more recently with OKTA for providing a SSO experience across all the corporate apps. The process for setting up Federated Authentication with an external identity provider is well documented. However, there are a couple of things that were not in the documentation that caught me off guard and broke my OKTA -> Sitecore claims mapping recently. In this article, I am going to share how to avoid those pitfalls.

To give you some context, I am mapping OKTA group membership to Sitecore roles as suggested in this Sitecore documentation. I have setup OKTA to pass groups claims to the identity server and mapping individual groups to Sitecore roles. For admins I am mapping the admin group claim to the Sitecore's isAdmin claim as suggested in this blog post by Aaron Bickle. My OKTA integration was working fine for few months until it suddenly stopped working. Users were getting error on login.
On investigation, it turned out to be users were not getting mapped to any Sitecore roles. During the investigation of this issue and fixes I tried here are the things I learned.

Misconfiguring claims mapping can lead to users getting mapped to all roles including admin

Due to the time criticalness of the issue and having not being able to find any recent changes to my claims mapping configuration or Sitecore instance I started looking for answers in all the federated authentication setup blogs and in an old blog about integrating with ADFS I found that the blogger used a slightly different way to configure the groups claims instead of what's in Sitecore documentation. Sitecore documentation suggests the below way to map groups claim to Sitecore role.
<ClaimsTransformation1 type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
  <SourceClaims>
    <Claim1 type="groups" value="Sitecore Developers" />
  </SourceClaims>
  <NewClaims>
    <Claim1 type="role" value="sitecore\Developer" />
  </NewClaims>
</ClaimsTransformation1>
The source claim value attribute should have the group name. The blog I referred has the group's name in between the source claim open and close tags as shown below.
<ClaimsTransformation1 type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
  <SourceClaims>
    <Claim1 type="groups">Sitecore Developers</Claim1>
  </SourceClaims>
  <NewClaims>
    <Claim1 type="role" value="sitecore\Developer" />
  </NewClaims>
</ClaimsTransformation1>
Being desperate to fix the issue asap I tried this new configuration, and it seems to have worked. Being part of the admin group, I was able to see my admin access after the change. However, this happiness was short lived as I realized everyone else is getting admin access even though they are in less privileged groups.

On digging into how the default Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation claims mapping provider works, I found that when the value attribute is not present the code is just mapping all the users to all the role claims as long as there is a source claim of type groups present. This would have been a disaster if this code was shipped to production. Having averted the disaster, I reverted to my original configuration.

So, what broke my code if there were no changes to it in months? I needed to look outside of Sitecore to find the answer which bring us to my other learning out of this.

The claim values are case sensitive

After scratching head for few more hours I took a much closer look into the incoming claims and noticed a small change. The incoming claims group value's casing has changed since I first configured the claims mapping. I was expecting the value Sitecore Developers instead I was getting Sitecore developers. Someone decided to change the OKTA groups casing without understanding how this would impact the systems integrating with it. Would this one letter case change have caused the issue? 

Once again on checking how the default Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation claims mapping provider works, I found out that the mapper uses StringComparision.Ordinal for comparing the incoming claim values to the source claim values configured. As the comparison is not case insensitive it broke my claims mapping. Having found the issue, I updated the source claim values to the new group values and everyone's happy to get their Sitecore access back.

Hope this saves someone from spending hours scratching their heads when their claims mapping stops working suddenly.

Comments

Post a Comment

Popular posts from this blog

SXA Scriban extension to get link field target URL

-
Scriban is the new templating language which was introduced in Sitecore 9.3, it replaces the obsolete NVelocity templates in the earlier versions. If you are upgrading from earlier versions of Sitecore and used a lot of NVelocity templates, you need to convert all your NVelocity templates to Scriban as NVelocity is no longer supported in Sitecore 9.3. Scriban is a powerful language with support to import your own .Net functions. Sitecore provides a rich set of Scriban extensions to use which meets most of the common requirements. You can find more about the out of the box Sitecore Scriban extensions here . While using Scriban to create custom markup which can't be achieved through other Rendering Variant fields I came across a requirement to wrap a section of HTML with an anchor tag targeting to an URL set in a link field in the template. In SXA we would set the link target field on the Rendering Variant and set the Is Link property value of the Rendering Variant field to W
Read more

How to ace your Sitecore .Net Developer 10 Certification Exam

-
Image
  I have been a Sitecore developer for five years and worked on various Sitecore projects, yet every time I take the certification exam it makes me nervous. From my conversations with the other Sitecore developers I worked with, even the most experienced Sitecore developers are nervous about failing the certification exam. They try to avoid taking the exam unless absolutely necessary. A few reasons for this could be, The exam is too expensive to fail. Most employers will only reimburse the fee for successful certification attempts. The score required to pass the exam is quite high (80%) compared to your academic exams.  The Sitecore training modules for exam competencies can be expensive. Not everyone gets a chance to work on the latest version of Sitecore. The exam competencies include areas of Sitecore you never had a chance to work on. In this blog post I will share my most recent experience of preparing and successfully completing the Sitecore .NET 10 Developer certification exam.
Read more

View and download Sitecore log files using Log Viewer

-
Image
As a Sitecore developer you would want to regularly monitor the log files for recurring errors and warnings and keep them clean. I am quite used to downloading my log files and running the tools like Sitecore Log Analyzer to filter and group errors and warnings.  As we started to productionise our website and apply the security hardening best practices, I ended up losing access to the logs folder and admin pages. To complicate the things further we started using containers to host our Sitecore instance with zero access to file system for developers, even when it is needed for troubleshooting issues.  The only way I could access the logs was using AWS Log Insights which gives you a stream of events without any option to download the full log file. It is especially difficult to troubleshoot issues when you need to correlate events from multiple logs which means you need to look for events across multiple log streams and try to put together the jigsaw puzzle to see the full picture. This
Read more