Sitecore Content Serialization (SCS) is a powerful feature for managing item data in source control, but it traditionally depends on the Sitecore Identity Server for authentication. In this post, we’ll explore how to configure SCS and the Sitecore CLI to work without the Identity Server.

In most cases, the use of Identity Server is not an issue and nearly all the solutions that we work on have switched to using the ID Server, even If they are not using Single Sign On with external providers such a Azure AD, Okta or Auth0.

This is of course fairly obvious - both the documentation state this and the login command itself states you need to use the url of the identity server.

dotnet sitecore login --authority https://<sitecore-identity-server> --cm https://<sitecore-instance> --allow-write true

The Challenge in a Complex Enterprise Environment

Recently we were working with a large pharmaceutical customer that needed some help to resolve some underlying architectural support to resolve process issues on their complex solution and codebase. Anyone who has worked with customers in this space will know these solutions often span hundreds of sites with multiple agencies working on the solution at any given time, and this case was no different.

One of the recommendations was to get the out of date item serialization working, which had previously been using TDS. Seems like a very simple suggestion, but this was a very complex codebase, and using Sitecore Content Serialization required using the aforementioned Identity Server. In this solution, which had been in place for a number of years, Identity Server had been disabled since it caused issues across multiple sites, and re-enabling it would have been both tricky and time-consuming..

Implementing the Workaround

Knowing full well that we needed to get the serialization in place in order to unblock some major process bottlenecks, we asked on Sitecore Community Slack if anyone had been able to get Serialization to work without ID Server. As expected, the community confirmed what the documentation already makes clear, or to use the alternative of Unicorn.

But if there was one person who would have figured out an alternative, it is Per Bering! He pointed us to his Sitecore Glitterfish (https://github.com/pbering/sitecore-glitterfish) project, a (very) lightweight Sitecore XM development environment for Docker. Take a look, since the entire thing runs on only a single container!

As a result of course, that means no Identity Server! In order to support the CLI, he has implemented code which handles the tokens and responses that the CLI expects when you login:

https://github.com/pbering/sitecore-glitterfish/tree/sqlexpress/src/Glitterfish/CliSupport

Once this has been implemented, you can install the CLI on the local machine as normal, and login using the same login command, but instead use the URL of the CM server for the authority parameter:

dotnet sitecore login --authority https://<sitecore-instance> --cm https://<sitecore-instance> --allow-write true

Adding Role Based Security

One additional benefit we got from this - since we had full control of the authentication code, we could add in some additional checks and balances so prevent users from logging and pushing serialized items/content in non-local environments. Since many of the developers had either sitecore\Developer or full Administrator privileges, they could in theory push directly from their local machine to the upper environments (remember, our entire engagement here focused on resolving architectural and process challenges and put in place best practices) - and just telling them not to do it seemed like it could be a little hopeful.

Just add in your own custom checks after the existing code to ensure the user is in the expected roles

var user = Sitecore.Context.User;
if (user == null || !user.IsInRole(@"agency\restricted role"))
{
    AccessDeniedResponse(args);
    return;
} 

So we added in our own login into the Authentication process, which would only allow specific users with specific roles to push/pull items. The CLI still needs a user when run in a DevOps process.

So serialization issues solved, and we could solve some other fundamental process and architectural issues on this mammoth solution. And the underlying issue that did now allow us to enable identity server in the first place? Don't worry, not forgotten, but something that can be resolved properly in due time. Which would also allow Single Sign On to be enabled! But this solution has been running for some time now without any issues :)

So if you ever really really need to run the CLI whilst having the ID Server disabled, now you know the workaround. Happy Serializing!