Frank Costoya

# No groups claim? No Problem!
## How to use App Roles instead of groups.

While [implementing federated authentication for another client](https://www.frankcostoya.com/blog/locking-down-intranet), I ran into a new issue. This client was only intending on using Azure AD for the back-end, which simplied the process greatly. I only need to create a User Builder class, implement the correct configs for Identity Server, and some small config changes for sitecore and _voila!_ we should be all done. Right? Nope think again. When testing, we ran into an issue where _some_ users were not getting the appropriate sitecore roles assigned to them! When I checked their account, I could see the UserBuilder class ran perfectly, so why no roles?

I had the user send me the token that was being generated for them. Using [jwt.ms](https://jwt.ms) I was able to decode the token, and I noticed something a bit strange....

```json
"_claim_names": {
  "groups": "src1"
},
"_claim_sources": {
  "src1": {
    "endpoint": "https://graph.windows.net/0aad2ef9-8871-4f4b-9f84-bb6fb9dc58de/users/9091fa67-7c39-42f1-a6ab-d4094cceb2fb/getMemberObjects"
  }
}
```


_Well thats not what we were expecting!_

Normally we're used to seeing a groups claim with the GUID's from the azure groups.... 

So after doing some research, it seems the issues is **The Azure ID token is limited to 250 groups.**. Now that might seems like a lot, but many groups have child, or inherited groups, which can cause their to be many more groups than expected. We found out that the users that we're not recivieng the proper roles in sitecore, were because they exceeded this limit. 

## The Solution 

Forget groups! We're going to pivot to App Roles. Within your application registration, we can create App Roles. These are similar to groups, but are specific only to this application. This fits our use case, because we are only creating these groups to assign the Sitecore roles. 

**Configuring in Azure**

1. Go to the App Registration, and on the left press Manifest. Inside the manifest, changes the groupMembershipsClaims to "null" and save the manifest. 
2. On the left menu inside the App Registration, click App Roles. Here we create the roles we need. For each role press + Create app role and fill with the following values: 
    * Display Name: "Role name "
    * Allowed Member Types: "Users/Groups"
    * Value: "RoleValue" (for example this could be "SitecoreAdmin")
    * Description: "Assigns the admin role for sitecore."
    * If done correctly, you should now see your App Roles inside your applications Manifest. 

3. Time to assign the roles to users. Leave the App Registration, and search for "Enterprise Applications" in the top menu in the Azure Portal. Find and select the app registration for your sitecore. 
4. Inside the Enterprise Applications menu for our application, press "Users and Groups" on the left menu.
5. To add a user with their role: 
    * press Add user/group 
    * Under Users press the "None Selected" link.
    * Click all the users who need the Admin role.
    * Under Select a role* press the "None Selected" link.
    * You should see the roles we created in the previous steps, assign these roles to the users.
    * In the bottom left, press the assign button. 
    * Repeat these steps for other roles.

Great! Now you should see the token looks a little different. Instead of a groups claim, we now see a roles claim, containing the assigned roles we created in Azure! It should look a little like this: 

```json 
"roles": [
    "SitecoreAdmin",
    "WhateverValueYouPutForYourRoles"
],
```

**Updating the Identity Server Configuration**

Now we need to update the Identity Server configuration to accept these app roles instead of the groups guid. This process is fairly straight forward. 

**OLD GROUP CLAIM**
```xml
<GroupToRole type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
    <SourceClaims>
        <Claim1 type="groups" value="GROUP GUID HERE" />
     </SourceClaims>
      <NewClaims>
          <Claim1 type="role" value="sitecore\Role Name" />
       </NewClaims>
</GroupToRole>
```
**NEW ROLE CLAIM**
```xml
<RoleToRole type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
    <SourceClaims>
        <Claim1 type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" value="AppRoleValue" />
     </SourceClaims>
     <NewClaims>
         <Claim1 type="role" value="sitecore\Role Name" />
      </NewClaims>
</RoleToRole>
```

As you can see, really we are only changing the \<SourceClaims\> section to use the role schema as the type instead of the string groups. And we are changing the value property from the guid, to the value created when making the App Role. 

After that you should be all done! Your token will now pass App Roles, and your sitecore instance is ready to accept them! Congrats!


medium_1000_F_410483387_Mmu44BiATG5AnWd8RQWjY7lUENPPtWF5.jpg

small_1000_F_410483387_Mmu44BiATG5AnWd8RQWjY7lUENPPtWF5.jpg

thumbnail_1000_F_410483387_Mmu44BiATG5AnWd8RQWjY7lUENPPtWF5.jpg

1000_F_410483387_Mmu44BiATG5AnWd8RQWjY7lUENPPtWF5.jpg

Resolving a common issue with Sitecore and Azure AD where the groups claim is not being received. A follow up to my previous post: Locking Down an Intranet with Sitecore Identity Server and Azure AD

No groups claim? No problem!

# Locking Down an Intranet with Sitecore Identity Server and Azure AD



For one of my recent projects, I was tasked with creating an intranet for a client. This intranet had a requirement to use Azure Active Directory as it's authentication source. I've found plenty of articles online that do this by directly connecting your CM server to Azure AD, but what if you wanted to use Sitecore Identity Server to normalize your claims? Sitecore provides us by default with a Azure AD plugin, which pretty much works automatically for the backend, but what about front end users? I'll go through the steps it took me to set this up. 



## Register an Application in Azure

First things first, we need to create an application in Azure to allow any of this to happen. 

1. Inside your Azure Portal, go to App Registrations and press + New Registration.
2. Name your App, and select the supported account type the suits your needs. (The first option fits most use cases)
3. For Redirect UI, we need to put the address to the Identity Server with the /signin-oidc at the end of the URL. Example: *id.sitecoreserver.com/signin-oidc*. Also set the Platform type to: *Web*.
4. Press Register! You should now be on the Overview screen. 
5. On the Overview panel, write down your Client ID and Tenant ID. We'll need these later when we configure the Azure AD plugin in Identity Server. 
6. On the menu on the left, press the Manifest option. Inside the manifest, update the `groupMembershipClaims` value to `SecurityGroup`.
7. Lastly go to the Authentication menu option. Under *Implicit grant and hybrid flows* check the box next to ID tokens and press save. 

Great. Now your application is registered in Azure!



## Configuring the Identity Server Plugin 

Now we can move to configuring your Identity Server. Make sure your have the Client ID and Tenant ID from the previous step 5. Here we will take claims from the azure token on login, and normalize them for use with our sitecore. The benefit of this, is really we are decoupling CM from Azure. Should your organization in the future decide to go away from Azure, you can swap out the Azure AD plugin, for another SSO service plugin, and you wont have to make any changes to your CM. The Azure AD plugin is given to us from Sitecore by default, so thankfully, we only really need to make some configuration changes. If you in the future planned on integrating with another SSO, you might need to code up your own plugin. 

1. First we need to enter in some general settings. In the top area we need to change a few things    

   `<Enabled>true</Enabled>`  

   First we need to enable the Azure AD plugin, simply changed the `<Enabled> ` to `true`

   `  <ClientId>{Place ClientId here}</ClientId>`

​       `<TenantId>{Place TenantId here}</TenantId>`

​    Remember the ClientID and TenantID we wrote down earlier? You'll want to place them in the top section as well.  

2. After configuring the top area, the rest of the configuration is where we setup our claims. In the example config, you should see some default options. We'll keep it simple here for the sake of the example. In this snippet, were setting all users in a specific group as admin, and then all users in another group as part of the intranet/User role. (intranet is not a default domain and you may need to create it)

   ```xml
   <AzureADUserToAdminUser type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
     <SourceClaims>
   	<Claim1 type="groups" value="{Group ID for all Sitecore Administrators}" />
     </SourceClaims>
     <NewClaims>
   	<Claim1 type="http://www.sitecore.net/identity/claims/isAdmin" value="true" />
     </NewClaims>
   </AzureADUserToAdminUser>
   <GroupToRoleIntranetUser type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
     <SourceClaims>
   	<Claim1 type="groups" value="{Group ID for all users of the Intranet}" />
     </SourceClaims>
     <NewClaims>
   	<Claim1 type="role" value="intranet\User" />
     </NewClaims>
   </GroupToRoleIntranetUser>
   ```

3. On top of assigning security roles, we also normalize user information sent through the token.

   ```xml
   <UPNTransformation type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
     <SourceClaims>
       <Claim1 type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" />
     </SourceClaims>
     <NewClaims>
       <Claim1 type="upn" />
     </NewClaims>
   </UPNTransformation>
   <NameTransformation type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
     <SourceClaims>
       <Claim1 type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" />
     </SourceClaims>
     <NewClaims>
       <Claim1 type="name" />
     </NewClaims>
   </NameTransformation> 
   <EmailAddressTransformation type="Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformation, Sitecore.Plugin.IdentityProviders">
     <SourceClaims>
       <Claim1 type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
     </SourceClaims>
     <NewClaims>
       <Claim1 type="email" />
     </NewClaims>
   </EmailAddressTransformation>
   ```



This is just a small sample of the type of claims you can transform and normalize for sitecore. More information on this in Sitecore's official docs [here](https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/configure-federated-authentication.html). 

4. Ok, now that we've input our information from Azure AD, save this file and restart the Identity Server in IIS. (Note: Identity server does not automatically restart when you edit a configuration file like on CM/CD, if you make more changes, you'll need to restart the server to see its effects.) Once the server restarts, go ahead and navigate to your `/sitecore/login` on your CM server. You should now see a new Azure AD button in your sitecore login!

<img src="https://frankcostoya.nyc3.cdn.digitaloceanspaces.com/e9b4d0f57bc1dea83d61122380bc6660.png" style={{ transform: "scale(0.5)" }} />


   

   Now users with backend access should be able to login using the Azure account! This works great for content editors and developers, but what about your front end users? Next we'll tackle this. 

   

   ## Using the Azure AD Plugin for your Intranet Users

   To utilize the Azure AD plugin for your front-end users. We need to add some patch configurations. In this section we will register Identity Server as a sub-provider for the front end, edit the website configuration to require login, and automatically set the login path to route to Azure (by doing this, your front-end users don't need to see the Sitecore login page, and skip directly to Azure AD login.)

   

   1. First lets create a patch configuration to register the Azure AD login as a sub-provider. Make sure this is inside your App_Config/Include folder. 

      ```xml
      <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
      	<sitecore role:require="Standalone or ContentDelivery or ContentManagement">
      		<federatedAuthentication>
      			<identityProvidersPerSites>
      				<mapEntry name="all sites" type="Sitecore.Owin.Authentication.Collections.IdentityProvidersPerSitesMapEntry, Sitecore.Owin.Authentication">
      					<identityProviders hint="list:AddIdentityProvider">
      						<identityProvider ref="federatedAuthentication/identityProviders/identityProvider[@id='SitecoreIdentityServer/IdS4-AzureAd']" />
      					</identityProviders>
      				</mapEntry>
      			</identityProvidersPerSites>
      			<identityProviders>
      				<identityProvider id="SitecoreIdentityServer/IdS4-AzureAd" type="Sitecore.Owin.Authentication.Configuration.DefaultIdentityProvider, Sitecore.Owin.Authentication">
      					<param desc="name">$(id)</param>
      					<param desc="domainManager" type="Sitecore.Abstractions.BaseDomainManager" resolve="true" />
      					<caption>Log in with Sitecore Identity: Azure AD</caption>
      					<icon>/sitecore/shell/themes/standard/Images/24x24/msazure.png</icon>
      					<domain>intranet</domain>
      				</identityProvider>
      			</identityProviders>
      		</federatedAuthentication>
      	</sitecore>
      </configuration>
      ```

      This configuration should work for the default implementation. What this configuration does is register your Azure AD plugin on Identity Server to be used on CM on the front-end, allowing it to be used for more than just the back-end authentication.

   2. Next, we need to edit your site configuration to require login, and tell it where users will login. This will vary depending on how your site is configured, but the general gist is under your `<site>` node you'll want to add `requireLogin="true"` and more importantly, you'll want to add `loginPage="$(loginPath)website/SitecoreIdentityServer/IdS4-AzureAd"` where "website" is your website name. The `(loginpath)` should be set by default if your installation that comes with identity server.

      

   After you add these patch configurations, go ahead and deploy to your CM and CD servers, and voila! Your site now will now automatically redirect users to login through Azure Active Directory! 

   

   Thanks for reading through, and I hope this works great for you. Should you run into any issues, feel free to message me on [LinkedIn](https://www.linkedin.com/in/frankiecostoya/) or even reach out to me via [email](mailto:fcostoyaprograms@gmail.com). 

   

   

   
   
   

   



small_locks.jpg

thumbnail_locks.jpg

locks.jpg

In this article, we setup our website to require federated authentication on the front-end using Azure Active Directory!

Hi, I'm Frank Costoya. I'm a full stack web developer.

Here on my website, you can find some information about the technologies I use, the projects and clients i've worked with, and some of my thoughts on my blog.

Latest Posts

No groups claim? No problem!

Locking Down an Intranet with Sitecore Identity Server and Azure AD

follow us