Azure Active Directory for Developers

You may never have to create another Sitecore account again

Introduction

In a previous post, I talked about why Single Sign On is the most important feature to enable early on in a project.

This is part two in a series on how to take Sitecore Identity to the Next Level. This article establishes a foundation by overcoming one of the biggest hurdles in implementing SSO with Azure Active Directory: creating and managing an Azure Active Directory organization, otherwise known as a tenant.

In a later post I’ll show you how to create your own tenant along with users and security groups. This eliminates the dependency on another team to manage a tenant for you, making it easier for your team to get up and running quickly.

If you follow these steps, you could expand on this concept by spinning up multiple Sitecore instances that are connected to the same AD tenant. You may never have to create another Sitecore account again.

Reference

As you are aware, Sitecore is built on Microsoft technologies, which are designed to run in Azure. While this article will give you the basics, I’m a huge proponent of Microsoft’s learning catalog. This gives developers a rich background in the technologies that they are using every day. If you want to review the official learning for Azure Active Directory, I highly recommend the Manage Identities and Governance in Azure learning path, which is part of the Azure Administrator certification path.

Tenant Creation

Azure Active Directory has several feature tiers. For the purposes of this demonstration, we only need the feature sets of the Free tier.

Source: https://docs.microsoft.com/en-us/learn/modules/configure-azure-active-directory/5-select-editions
  1. Visit the Azure Portal
  2. Creating an Azure Active Directory tenant is different from a standard Azure resource. You can access it from your Home screen
    or visit this url: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview
  3. You can then select ‘Manage Tenants’, which provides a list of all the Active Directory tenants that you are a member.
  4. From here, you can select the ‘Create’ button to create your own tenant
  5. This will start the tenant creation ‘wizard’ with the Basics. Select ‘Azure Active Directory’
  6. Click the ‘Next: Configuration’ button
  7. Enter your organization name and initial domain name. IMPORTANT: The initial domain name field must be unique and will have `.onmicrosoft.com` appended to it.
  8. Select ‘Next: Review + create’
  9. Double-check your initial domain and then click the ‘Create’ button

In Summary

You now know how to create your own, free Active Directory tenant. You can experiment with some of the premium features or start adding users and groups. A word of caution: Azure AD tenants are foundational. The more you add to it, the harder it is to delete the organization if you don’t need it.

Up Next

  1. Single Tenant Azure / Multi-tenant Sitecore – setting up users, groups and app registration for a Sitecore development team
  2. Securing Headless Sitecore using Vercel SSO
  3. Securing Sitecore Authoring sites

Next Level Sitecore Identity

Introduction

Single Sign-On (SSO) is the most important feature to enable early in application development. Nobody wants to manage another password, especially across multiple environments. Allowing stakeholders to login with their existing credentials dramatically accelerates user acquisition and engagement when designing a world-class digital experience.

Sitecore has integrated with Azure Active Directory (and other authentication providers) for many years using tools available in the marketplace. It wasn’t until the introduction of Sitecore Identity in Sitecore 9.1 that the integration with Azure Active Directory came Out-Of-The-Box (OOTB).

“You can use Federated Authentication for front-end login (on a content delivery server), and we recommend you always use Sitecore Identity for all  Sitecore (back-end) authentication.”

Sitecore Identity 10.2 Documentation

There are lots of helpful articles from the Sitecore community that provide detailed steps on how to configure the Content Management and Identity roles to use popular providers such as Azure Active Directory, Okta and others.

Instead, I plan to cover more of the front-end benefits of Single Sign-On and Sitecore Identity.

Up Next

Over the next few posts, I’ll be covering some topics that are not discussed as frequently or in much detail. Since I work primarily with Azure, I’ll be focusing on Azure Active Directory as the provider of choice:

  1. Azure Active Directory for Developers
  2. Securing Headless Sitecore using Vercel SSO
  3. Securing Sitecore Authoring sites

Sitecore MVP Journey

For those who don’t know me or haven’t met me, my name is Chet Potvin and I live with my family in the suburbs of Chicago. I’ve been working with the Sitecore platform for almost 5 years. I’ve enjoyed working with Sitecore because of its flexibility and potential. I’ve picked up a lot of experience on the Managed Services and Implementation sides of the coin. I have applied for the prestigious Sitecore MVP award twice and have yet to be selected.

This year, Sitecore launched an MVP mentorship program that pairs prospective MVPs with a mentor. As a new mentee, I’ve been working with my mentor to establish a roadmap and set regular meetings to track progress. The purpose of this post is to publish a plan and possibly inspire any other Sitecore experts to pursue their own goal of becoming an MVP.

As I continue grow my Sitecore career, my primary goal is to give back to the community that has given me so much. This all starts with this post. One of the toughest things for me is to put a vision or experience down on paper. It takes me a long time; however I know my Sitecore experiences can help others with their projects. Therefore, my goal is to post twice a month to further myself and share my knowledge.

Some of the future topics that I’ll be polling the community:

  1. Headless Blueprint – This is a set of tools, walkthroughs and design systems that I’ve used to successfully deliver Headless sites for my clients.
  2. Sitecore + Vercel – A match made in heaven
  3. Preparing for XM Cloud – Sitecore SaaS is getting closer. What can we do for our clients to get them ready?
  4. Upping Your Relevancy – it’s no secret that I love Solr. I want to share more of what I’ve learned in this area.

If you’re jumping into the Sitecore Community Pool or these topics piqued your interest, please reach out and say ‘Hi’.

Package Managers: Nuget

Why is packaging important?

When you purchase a product, the first thing that you notice is the packaging. What do you think when you first open a product with thoughtful packaging? For me, there’s an initial assumption of quality based on the care taken to prepare the item for consumers.

Similar assumptions can be drawn from well-packaged software. When a development team is tasked with maintaining, improving or recreating a solution, the first impression of that software is critical. Packaging is the first indicator of quality. If the team determines the code base to be of low quality, they may opt for a total rewrite instead of simple maintenance increasing costs in both the short and long term.


With any Sitecore solution, there are portable libraries that need to be included with the solution to facilitate environment setup. In several cases, I’ve seen development teams add those portable libraries into source control. Most of the time this is because the team is unaware of other options. This article discusses package managers and how your team can leverage these tools to create your own distributable packages.

Source control is designed for pre-compiled code. Adding compiled code to your repository creates bloat in your repo and makes versioning and upgrades very challenging. Package Managers solve this problem and others.

What is a package manager?

package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. As the name suggests, package managers deal with packages: collections of files that are bundled together and can be installed and removed as a group.

What is a package manager? (archive.org)

There are a myriad of popular package managers that you use everyday: Nuget, NPM, Chocolatey to name some of the most common for dot net devs. When I mention Nuget, most developers are very familiar with the consumption of public packages posted on nuget.org or public Sitecore packages at myget.org.

Options for publishing and hosting your own packages depend on who you want to consume those packages. If you can open-source your code, hosting in a public feed like nuget.org is an option. For others, their code is proprietary and should only be distributed amongst a small group. Private feeds accomplish this goal. Myget will host a private feed for you, but at a cost.

Most people aren’t aware that you can host your very own private packages directly within Azure DevOps using the Artifacts feature. I use these feeds to publish Sitecore support, TDS and Helix foundation modules for my teams. This feature is free if you have a Visual Studio subscription. I’m going to talk about Helix Modules in a later post, so for now I’m going to focus on the Sitecore Support use case.

One ‘perk’ of being a Sitecore certified developer is that I get access to the Sitecore support pipeline. When the support team determines that a patch is required, the Sitecore team will generally compile some code and zip the library up with some instructions for installation. I wish support could provide these libraries as part of a feed, but the overhead of maintaining that feed for each customer would become unmanageable pretty quickly.

Instead, I use a tool called Nuget Package Explorer to create a package with the necessary assemblies included and then publish to my Azure DevOps Artifacts feed. Let’s walk through those steps:

Create your Nuget Package

  • Install Nuget Package Explorer using Chocolatey
choco install nugetpackageexplorer
  • Download your files from Sitecore support
  • Unzip those files to a folder on your machine, i.e.
c:\nuget\lib
  • Open Nuget Package Explorer
  • Create a new package
  • Update the package metadata on the left-hand side by clicking on the icon with the card and the pencil. The key required attributes to update here are:
    • Id (i.e. Sitecore.Support.999999)
    • Version – This is very important. I’ve left the default here in the past, but the Sitecore version number would help developers understand whether the package applies to their solution.
  • Add content to your package by right-clicking on the ‘package contents’ pane and selecting ‘Add Lib Folder’
  • Right-click on the ‘lib’ folder and select ‘Add Existing File…’
  • Select your binaries
  • Save the package to disk. i.e.
C:\nuget\localrepo

Publish Your Package

  • Create your feed
  • Connect to your feed
  • Select Nuget.exe
  • Download a recent copy of nuget to a local folder. i.e.
c:\nuget\
  • If you don’t have a recent copy of Visual Studio on your machine, you can download and install the credential provider
  • Using the nuget cli, push your package to your feed with Powershell i.e.
c:\nuget\nuget.exe push -Source "My Nuget Feed" -ApiKey az "C:\nuget\localrepo\Sitecore.Support.999999.nupkg"
  • If prompted, enter your ADO credentials
  • With the publish complete, you can now add your feed url to Visual Studio or using your solution’s nuget.config
  • Browse for your package in Visual Studio
  • Install the package to any dependent projects

Conclusion

This does require a bit more time to setup, but it will save your team a ton of time when setting up their development, testing and production environments.

Now that I’ve explained the purpose of Package Managers and how to host and publish to your own private Nuget feed, the next post will discuss the Principles of Package Management and how those principles are applied to Sitecore Helix.

Sitecore 9.1 using Solr as a Service

In a hurry? TL;DR

Background

I run a Sitecore study hall with my development team for the purpose of establishing a solid foundation for new Sitecore developers and to keep certifications current for our experienced team members.

For every one of my cohorts, the single most challenging aspect of working with Sitecore 9.x is the installation of Solr

Cheeto

I cut my teeth on Solr when I first started learning Sitecore and I had zero experience with building a search index. Two years later I can say that I’m an enthusiast.

Many developers may dismiss search as a second class citizen when it comes to the installation and configuration of your Sitecore installation.

Your search index is just as important to the Sitecore infrastructure as your SQL Server repository.

Cheeto

If you want a site that actually performs well in your development environment and at scale, you should build your site so that your search index can also scale.

Many architects will leverage Azure Search for staging and production environments. This is a reasonable option, but I have not had a good experience. This is primarily due to the lack of an on-premise option for installing Azure search on a developer’s machine. This leads to environments that do not mirror each other in terms of foundational technology, making it a challenge to support.

I’m going to walk you through the process of setting up Sitecore to run on a cloud-managed instance of Solr. The provider I’ve chosen is SearchStax, because of their existing relationship with Sitecore.

Key Terms

  • SolrCloud – A high availability option for running Solr
  • Zookeeper – A centralized configuration repository (minimizes configuration at the node level)
  • Node – a single instance of Solr. A node can host multiple cores.
  • Core – A physical document repository
  • Shart – When you fart and mess your pants.
  • Shard – A subset of documents within a collection
  • Collection – A logical pointer for a set of documents or a bundle of shards (thankfully not sharts)

Read more on Solr’s site

Standalone vs SolrCloud

Solr and SolrCloud are not separate things; Solr is the application while SolrCloud is a mode of running Solr. The alternative to running Solr in SolrCloud mode is running it in standalone mode which is most, if not all of our installs today.

Advantages of SolrCloud

  • Centralized configuration management using ZooKeeper
  • Index replication
  • Failover
  • Load balancing
  • Distributed queries
  • Scalability

Search Topologies

SCH is short for Search

  • SCH0 – Your search node is running on the same machine as Sitecore.
    • 0 dedicated instances.
  • SCH1 – A single search node on its own, dedicated machine
  • SCHx – Multiple search nodes running in a clustered environment

SCH1 and SCHx are typically setup as virtual machines or using a hosted provider. Setting up your own virtual machine requires in-depth knowledge of Solr configuration, while a hosted provider eliminates the need for this knowledge.

This walkthrough will install a SCH1 topology against Sitecore 9.1 (XP0) using a hosted provider.

Configuration Steps

I assume that you already have a vanilla version of Sitecore 9.1 installed on your machine. If you don’t, I recommend using SIFless 2.2 with the SCH0 topology (Solr installed locally).

  1. Create single Solr node (SCH1) in SearchStax ~ 10 mins
  2. Add basic security ~ 1min
  3. Run Zookeeper and Collection Scripts ~ 5 mins
  4. Update Sitecore ConnectionString ~ 1 min
  5. Populate ManagedSchema ~ 5 min
  6. Rebuild indexes ~ 5 min

Creating your Solr Node in SearchStax

SearchStax offers a 14 day free trial which has allowed me to experiment with their offering and establish whether it can be configured to work with Sitecore 9.1.

https://app.searchstax.com/freetrial/

After signing up for the trial, you will create your deployment within the Cloud Manager.

We’ll be working within the CloudManager in this example

The deployment requires:

  • Name
  • Cloud Provider
  • Region
  • Plan
  • Tier
  • Solr Version

For the trial, your options are limited to AWS as the cloud provider and you can create either a single or clustered node in the lowest pricing tier. For this example, Solr 7.2.1 is being used for Sitecore 9.1.

An example single node deployment (SCH1)

The deployment process takes a few minutes and you will receive an email once the deployment is completed.

Securing your Node

Adding security to a SearchStax node is simple. You can add IP address whitelisting or basic authentication with the click of a button. I’m choosing basic auth to demonstrate the functionality. Whitelisting is tricky in a Sitecore PaaS environment since the App Services have a range of outbound IP addresses.

Under your server settings, select Security and then Auth.

First you’ll need to enable Authentication. This will force a restart of your node.

Next, add a user. I’m naming my user searchuser to follow Sitecore’s database user naming standards like: masteruser, coreuser, etc. I give this user admin privileges because it will need to be able to create, read and write collections.

Keep this username and password handy as you’ll need it later for the automated script that creates the Solr collections.

Solr Collection Configuration with Zookeeper

The next step is to configure Solr collections to match the default Sitecore indexes. Since SolrCloud can have multiple nodes, it doesn’t make sense to house the configuration for each collection within the node. A Zookeeper ensemble helps us isolate the configuration so that it can be managed centrally.

Sitecore and SearchStax do provide some documentation on configuration within ZooKeeper, but at the time of writing, these documents fail to point out that each collection requires its own configuration uploaded to Zookeeper. This detail took many hours to resolve.

The documentation above also uses the ZooKeeper CLI to upload the configuration files. This batch file has different versions based on the version of Solr you are using and is not particularly easy to use with Powershell. Luckily for us, SearchStax has a useful REST API which abstracts away the details of the Zookeeper CLI.

I’ve managed to automate this entire process using a pair of Powershell scripts.

IMPORTANT: Powershell historically has not done a good job with multipart form submissions. For this reason, the Zookeeper configuration requires Powershell Core. If you use Chocolatey, you can easily install the package in Windows with this command:

choco install powershell-core

Before you can run the scripts, you will need to collect some required parameter information:

  • Search Stax Account Name
  • Search Stax Deployment ID
  • Search Stax Username
  • Search Stax Password
  • Solr Cluster Host
  • Solr Username
  • Solr Password

You can find your Search Stax Account Name in the top-right corner of the screen when you are logged-in.

You can find your Deployment ID when you click on the deployment you just created within the Cloud Manager. The deployment ID is in the url:

https://app.searchstax.com/admin/deployment/ssXXXXXX/servers/

The Search Stax username and password are used for connecting to the Zookeeper API provided by SS. You created these items when you signed up for your SS account.

The Solr Cluster Host is located under the Server management tab and looks similar to this:

The Solr username and password come from the basic auth security that you setup against your Solr node in the steps above.

TL;DR;

Now that you’ve collected all of your parameters, head on over to Github to clone the repository for automating this setup process:

https://github.com/ChetPotvin-RP/sitecore9-solrcloud-automation

Once you’ve cloned the repo locally, you’ll see that there are three Powershell scripts in the .\scripts folder.

Open the file named: 1-Invoke-SearchStax-ConfigureSolr-Demo.ps1 and fill in the parameters

#SS = Search Stax

.\2-Write-SitecoreZookeeperConfiguration.ps1 `
	-SearchStaxAccountName "{Your SS Account Name}" `
	-SearchStaxDeploymentId "{Your SS Deployment Id}" `
	-SearchStaxUsername "{Your SS Username}" `
	-SearchStaxPassword "{Your SS Password}" `
	-SitecoreConfigZipFileName "sitecore_configs.zip" `
	-CollectionPrefix "fatstax"

.\3-Create-SitecoreSolrCollections.ps1 `
	-SolrHost "https://{Your Solr Instance}.searchstax.com" `
	-Username "searchuser" `
	-Password "{Your Basic Auth Password}" `
	-CollectionPrefix "fatstax"	

Execute this script from Powershell Core. After each configuration is uploaded and each collection is created, you should receive a Success or Failure message.

Connecting Sitecore to the Hosted Node

Once you’ve uploaded your Zookeeper configuration and created the Sitecore collections, you’ll connect Sitecore to your Solr instance. As you may know, there are several connection strings in Sitecore 9.1 that will need to be updated:

  • {WebRoot}\{SitecoreSiteName}\App_Config\ConnectionStrings.config
  • {WebRoot}\{xConnectSiteName}\App_Config\ConnectionStrings.config
  • {WebRoot}\{xConnectSiteName}\App_Data\jobs\continuous\IndexWorker\App_Config\ConnectionStrings.config

The connection string follows this format to allow the use of basic authentication:

<add name="solr.search" connectionString="https://{username}:{password}@{solrhost}/solr" />

The xConnect connection string is a little different and includes the xDB collection name as part of the route:

<add name="solrCore" connectionString="https://{username}:{password}@{solrhost}/solr/fatstax_xdb" />

It’s a good idea to restart the Sitecore and xConnect sites in IIS after making these connection string changes.

Populate the Managed Schema

Next you’ll need to login to Sitecore and open the Control Panel. Under the Indexing group, select ‘Populate Solr Managed Schema’

Select all of the indexes and click the Populate button

Rebuild the Indexes

Next you’ll need to rebuild the indexes within the Control Panel. Select the indexing manager, select all of the indexes and hit the Rebuild button.

After-Thoughts

I have not found any SIF templates that support SolrCloud installation. I’m sure that will be the topic of a later post.

The two documents provided by Sitecore and SearchStax indicate that you should append ‘;solrCloud=true’ to the end of your connection strings. I have not had any luck with this configuration.

Additional Resources