Hi,

We have a CMS 12 setup that uses the Content Delivery API (version 3.6.0), where we want all the API endpoints to require authentication – preferably restricted to specific roles.

This is easily accomplished by setting the DisableScopeValidation option to false when adding the API:

services.AddContentDeliveryApi(currentAuthScheme, options =>
{
    options.DisableScopeValidation = false;
});

By default, this will require a scope (see https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-protected-web-api-verification-scope-app-roles?tabs=aspnetcore for info about scopes) called "epi_content_delivery", but other scopes can be added by means of "options.AllowedScopes.Add("some_scope")".

If nothing else is done, no users at all are able to acces the API. (A response header will complain about a missing scope.) Thus, users must somehow be assigned scopes.

For authentication methods that are set up with an expilcit call to the AddCookie() method, it was possible with some experimentation to find a way of doing that through the OnSigningIn event. For example, with WsFederation:

services
    .AddAuthentication("signin-scheme")
    .AddCookie("cookie-scheme", options =>
    {
        options.Events.OnSigningIn = async context =>
        {
            // For example, assign the "epi_content_delivery" scope to any user who has the "WebAdmins" role
            if (context.Principal?.Identity is ClaimsIdentity claimsIdentity &&
                claimsIdentity.Claims.Any(c => c.Type.EndsWith("role") && c.Value == "WebAdmins") &&
                claimsIdentity.Claims is IList<Claim> claims)
            {
                claims.Add(new Claim("scope", "epi_content_delivery"));
            }
            await Task.CompletedTask;
        }
        options.Events.OnSignedIn = async context =>
        {
            if (context.Principal?.Identity is ClaimsIdentity claimsIdentity)
            {
                var synchronizingUserService = context.HttpContext.RequestServices.GetRequiredService<ISynchronizingUserService>();
                await synchronizingUserService.SynchronizeAsync(claimsIdentity, new[] { "scope" });
            }
        };
    })
    .AddWsFederation("signin-scheme", options =>
    {
        options.SignInScheme = "cookie-scheme";
        options.SignOutScheme = "cookie-scheme";
        options.MetadataAddress = "https://...xml";
        options.Wtrealm = "http...";
    });

With the above code in Startup.cs, users who are authenticated with WsFederation and have the WebAdmins role will be able to access the Content Delivery API.

However, how can the same thing be accomplished for users who are signed in with the built-in authentication – "EPi_AspNetIdentityUserProvider", added with "services.AddCmsAspNetIdentity<ApplicationUser>()"? With the Content Delivery API for CMS 11, it was easy, since the API options allowed roles that could access the API to be specified directly. But with CMS 12, we have to specify scopes instead.

Maybe I am missing something that is obvious to people with better understanding of scopes in ASP.NET Core, but I cannot find a way of adding the "epi_content_delivery" scope (or any other scope) to the claims associated with users authenticated by "EPi_AspNetIdentityUserProvider".

Presumably, there are ways of overriding various stages of the "EPi_AspNetIdentityUserProvider" authorization handling, but I do not know where to start. Also, for a seemingly simple task like this, we would prefer a simple solution, similar to the OnSigningIn event code that works for WsFederation – i.e. preferably not something where several default authorization handling classes need to be wrapped and customized.

It would have been good if https://docs.developers.optimizely.com/content-cloud/v1.5.0-content-delivery-api/docs/breaking-changes-version-3 that states "MinimumRoles: Obsoleted. Use ContentDeliveryApiOptions.AllowedScopes instead to control who can make API calls." had included an example of a simple way of achieving that in connection with the built-in CMS user management.