Federated Identity Server users incompatible with SPE Security

[jdylanmc]

Following along with a blog post similar to this one: https://sitecore.derekc.net/setting-up-azure-active-directory-integration-with-sitecore-identity-server-sitecore-9-1/, you can set your Sitecore website up to authenticate users through 3rd party services, such as Azure Active Directory.

When you do this, Sitecore creates a persistent user for the user who is authenticating: https://doc.sitecore.com/developers/91/sitecore-experience-manager/en/using-federated-authentication-with-sitecore.html#UUID-2cc3b983-72ec-afe0-0b52-b2f9193c6a02_id_configuring-content-delivery-and-content

However, the federated persistent user isn't a "full" user in the Sitecore ecosystem. They're more like a virtual in-memory user. When logging in with a federated user, you can check the roles associated with their account via Sitecore.Context.User.Roles. This will show you all roles that have been mapped back to the user from their federated claims. However, when you check Sitecore.Security.Accounts.User.FromName(userName, false).Roles, you will always see zero roles associated with the account. This is because roles from federated claims are not saved back to the core database.

If you take a look at ServiceAuthorizationManager, line ~48, you will see User.FromName("username", false); being used for authorization checks: https://github.com/SitecorePowerShell/Console/blob/master/Spe/Core/Settings/Authorization/ServiceAuthorizationManager.cs

This is incompatible with federated user accounts.

Expected Behavior

1. Configure a security role called "sitecore\ScriptUser" in sitecore.
2. Grant access to execute Sitecore Powershell scripts to all users within the role of sitecore\ScriptUser. The right-click context menu is considered for this test case.
3. Configure Sitecore Identity Server to authenticate users from a 3rd party source, such as Azure Active Directory.
4. Create a role in Azure Active Directory for "Azure Script User", and map this back to the "sitecore\ScriptUser"
5. Login with an Azure Active Directory account who has the "Azure Script User" role.
6. Observe that this user can perform script executions via the right click context menu.

Actual Behavior

User cannot access right click context script menu

Steps to Reproduce the Problem

See expected behavior. I can assist with reproduction if needed. This is occurring in both SPE 5.0 and 5.1, but I believe it also exists in 6.x series.

• Tested issue with clean install of Sitecore and the latest available version of SPE.

• Asked questions on the Sitecore Slack Chat channel.

• Reviewed questions and answers on the Sitecore Stack Exchange.

[michaellwest]

Seems at the moment that this is a limitation with Sitecore as noted here.

There are a number of limitations when Sitecore creates persistent users to represent external users. Sitecore does not support the following features for such users:

• Reading and deleting roles of external users in the User Manager because these roles are not stored in Sitecore.
• ...

[michaellwest]

I dug in a little more and turns out that the extension method Sitecore.Extensions.IdentityExtensions, Sitecore.Kernel parses the role claims and return the list of user roles. I imagine this list of claims is only available for the current user context user, not persisted users.

[darjimaulik]

Hi @alan-null and @michaellwest ,
I took the latest code(not release) to check if it fixes the issue. But with Sitecore 9.3, I am still seeing the same issue.

When using the Azure AD to login to Sitecore, I am not able to get the elevated privileges in PowerShell ISE. I have debuged the code as well, it looks like the code does set the allowedByRole property to True but after that, it still throws error on front end.

[yaliuCochlear]

Hey @michaellwest , has this issue been fixed with version 6.3?

[michaellwest]

Unfortunately no progress has been made on this item.

[michaellwest]

@darjimaulik Does the Scripts context menu appear for you?

[darjimaulik]

Will try to check. I moved to another project where we don't have the Fed Auth. But I can check with other teams in my org to check.