Hi, replying to my own post, I found by experimentation that the CMS UI language is controlled by the shell profile setting “episerver:ui:preferredlanguage”. The documentation page https://docs.developers.optimizely.com/content-management-system/docs/shell-profile describes how to read and manipulate shell profile settings. The following code successfully changes the UI language to Swedish for the logged-in user, regardless of whether the user is logged in through CmsAspNetIdentity or WsFederation:

// Assuming httpContext contains the current Microsoft.AspNetCore.Http.HttpContext object
if (httpContext.User?.Identity is var identity && identity?.IsAuthenticated == true)
{
    var repository = httpContext.RequestServices.GetInstance<IProfileRepository>();
    var profile = repository.GetOrCreateProfile(identity.Name);
    if (!profile.Settings.TryGetValue("episerver:ui:preferredlanguage", out var preferred) || preferred as string != "sv")
    {
        profile.Settings["episerver:ui:preferredlanguage"] = "sv";
        repository.Save(profile);
    }
}

Still, it would be very nice if it were possible to enable the “My Settings” interface for users who are synced by means of ISynchronizingUserService. Correcting my previous statement, those users do have a “My Settings” link:

However, the settings view is blank:

When the user is logged in by means of WsFederation and ISynchronizingUserService, the browser console reports a 404 error for the following path when the “My Settings” page is loaded: /EPiServer/EPiServer.Cms.UI.Settings/UserInformation/Get

There are no errors shown in the Log Stream in the Integration environment and no exceptions written when running locally, just a 404 response to the browser when visiting the link.

For the exact same “/EPiServer/EPiServer.Cms.UI.Settings/UserInformation/Get” path, there is a “200 OK” response containing JSON data when the user is logged in with CmsAspNetIdentity.

What version are you on? 'My settings' should work regardless authentication type.

Thank you answering Johan. It has never worked for the WsFederation-authenticated users, over 4 months with a couple of upgrades. Currently, we are a little bit behind the latest version, due to an incompatibility between the ImageVault plugin and EPiServer.CMS.TinyMce above 4.1.1. These are the version numbers that we are using:

    <PackageReference Include="EPiServer.CMS" Version="12.18.0" />
    <PackageReference Include="EPiServer.Hosting" Version="12.14.0" />
    <PackageReference Include="EPiServer.Framework" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore.HtmlHelpers" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore.TagHelpers" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore.Mvc" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore.Routing" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.AspNetCore.Templating" Version="12.14.0" />
    <PackageReference Include="EPiServer.CMS.TinyMce" Version="4.1.1" />
    <PackageReference Include="EPiServer.ContentDeliveryApi.Cms" Version="3.7.0" />
    <PackageReference Include="EPiServer.CloudPlatform.Cms" Version="1.3.1" />
    <PackageReference Include="ImageVault.EPiServer.UI" Version="12.19.7" />

What could be causing the “/EPiServer/EPiServer.Cms.UI.Settings/UserInformation/Get” path to return 404 for some logged-in users but not for others? Perhaps there is some expected information missing from the ClaimsIdentity that we get from the WsFederation login?

Since the ISynchronizingUserService examples in the documentation use OpenID Connect rather than WsFederation, maybe there is some difference in the data supplied in the ClaimsIdentity by each type of login, and WsFederation might not have been tested as much as OpenID Connect?

If we knew precisely what ISynchronizingUserService expects to find in the ClaimsIdentity in order to populate the user information properly, we could make sure to amend the content accordingly, but I have not been able to find any documentation on that.

This was actally fixed in EPiServer.CMS 12.20.0. 

Thank you Johan. Unfortunately, we cannot test that, due to the ImageVault incompatibility. According to ImageVault, there will be a workaround released in the upcoming 4.4.0 version of EPiServer.CMS.TinyMce. Until then, we are stuck with EPiServer.CMS 12.18.0.

Any idea when EPiServer.CMS.TinyMce 4.4.0 might be available?

Most likely early next week.

Hi Johan, I am sorry to say that we have now upgraded to EPiServer.CMS 12.20.0, and the problem is still exactly the same. That is, “/EPiServer/EPiServer.Cms.UI.Settings/UserInformation/Get” responds with 404 for users that are synced from WsFederation.

I also deleted references to my user from the tblSynchedUser and tblSynchedUserRelations tables and logged in again, and the problem was still the same.

This probably brings us back to the question of what exactly Optimizely CMS expects from the claims identity for ISynchronizingUserService to work properly.

The user name (“name” in the claims list) is in the format “LASTNAME Firstname” with a space between the last and first names. Perhaps that might matter? There is also a claim called “nameidentifier” containing the Active Directory login name of the user, but that value is not added to tblSynchedUser.

Below is a serialization of a typical claims identity that is received from WsFederation and passed to the ISynchronizingUserService call:

{
  "AuthenticationType": "AuthenticationTypes.Federation",
  "IsAuthenticated": true,
  "Actor": null,
  "BootstrapContext": null,
  "Claims": [
    {
      "Issuer": "http://login.clientdomain.com/adfs/services/trust",
      "OriginalIssuer": "http://login.clientdomain.com/adfs/services/trust",
      "Properties": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format": "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
      },
      "Type": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
      "Value": "loginname",
      "ValueType": "http://www.w3.org/2001/XMLSchema#string"
    },
    {
      "Issuer": "http://login.clientdomain.com/adfs/services/trust",
      "OriginalIssuer": "http://login.clientdomain.com/adfs/services/trust",
      "Properties": {},
      "Type": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
      "Value": "LASTNAME Firstname",
      "ValueType": "http://www.w3.org/2001/XMLSchema#string"
    },
    {
      "Issuer": "http://login.clientdomain.com/adfs/services/trust",
      "OriginalIssuer": "http://login.clientdomain.com/adfs/services/trust",
      "Properties": {},
      "Type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
      "Value": "WebAdmins",
      "ValueType": "http://www.w3.org/2001/XMLSchema#string"
    },
    {
      "Issuer": "http://login.clientdomain.com/adfs/services/trust",
      "OriginalIssuer": "http://login.clientdomain.com/adfs/services/trust",
      "Properties": {},
      "Type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
      "Value": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
      "ValueType": "http://www.w3.org/2001/XMLSchema#string"
    },
    {
      "Issuer": "http://login.clientdomain.com/adfs/services/trust",
      "OriginalIssuer": "http://login.clientdomain.com/adfs/services/trust",
      "Properties": {},
      "Type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant",
      "Value": "2023-06-09T13:23:40.951Z",
      "ValueType": "http://www.w3.org/2001/XMLSchema#dateTime"
    },
    {
      "Issuer": "LOCAL AUTHORITY",
      "OriginalIssuer": "LOCAL AUTHORITY",
      "Properties": {},
      "Subject": null,
      "Type": "scope",
      "Value": "epi_content_delivery",
      "ValueType": "http://www.w3.org/2001/XMLSchema#string"
    }
  ],
  "Label": null,
  "Name": "LASTNAME Firstname",
  "NameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "RoleClaimType": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
}

Hi Johan and others who may be interested in this issue,

As I mentioned above, EPiServer.CMS 12.20.0 still had this problem, and then I did not check for it over the next few versions, as we were mostly concerned with issues around inline blocks when testing successive upgrades. But I just discovered that in version 12.22.2 (along with EPiServer.CMS.Core 12.16.0), the “My Settings” functionality works perfectly well for WsFederation users who have been synchronized by means of ISynchronizingUserService.

No changes to any code or configuration were necessary – just the package upgrades.