Since ASP.NET Core 7, you can use the built-in rate limiting middleware to rate limit your APIs. You can apply the EnableRateLimiting and DisableRateLimiting attributes to add rate limiting on a controller or endpoint level. In this article, we will go through how you can configure and utilize different rate limiting strategies for Umbraco APIs.

What is rate limiting?

Rate limiting helps control the number of requests to an API, typically within a specified time frame or based on other parameters. This ensures the stability, availability, and security of your APIs. The key benefits are:

• Preventing server or application overload

• Improving security and protecting against DDoS attacks

• Reducing unnecessary resource usage, thereby cutting down on costs

Configuring rate limiting

You can configure rate limiting in Umbraco by composition. To use the middleware, you need to register the rate limiting services first:

public class ApiRateLimiterComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddRateLimiter(rateLimiterOptions =>
        {
            // Default is 503 (Service Unavailable)
            rateLimiterOptions.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

            // Write your code to configure the middleware here (rate limiting policies)
        });
    }
}

After that, you have to apply the RateLimitingMiddleware by creating an Umbraco pipeline filter. UseRateLimiter() must be called after UseRouting(), therefore we use the PostRouting to make sure this happens in the correct order:

public class ApiRateLimiterComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.Configure<UmbracoPipelineOptions>(options =>
        {
            options.AddFilter(new UmbracoPipelineFilter("UmbracoApiRateLimiter")
            {
                PostRouting = postRouting =>
                {
                    // Apply the RateLimitingMiddleware
                    // Must be called after UseRouting()
                    postRouting.UseRateLimiter();
                }
            });
        });
    }
}

With the set-up in place, let's take a look at some limiter options.

Global limiter

Inside AddRateLimiter() we can use the GlobalLimiter option to set a global rate limiter for all requests:

            // Write your code to configure the middleware here (rate limiting policies)

            // Use GlobalLimiter for all requests
            rateLimiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
            {
                return RateLimitPartition.GetFixedWindowLimiter(
                    partitionKey: httpContext.Request.Headers.Host.ToString(), 
                    partition => new FixedWindowRateLimiterOptions
                    {
                        PermitLimit = 2,
                        Window = TimeSpan.FromSeconds(10),
                        AutoReplenishment = true
                    });
            });

In the above example, we have added a FixedWindowLimiter and configured it to automatically replenish permitted requests and permit 2 requests per 10 seconds. There are different algorithms and techniques for implementing rate limiting, which can vary depending on your use case. For more information, check the currently supported rate limiter algorithms.

Limit specific endpoints

If you want to be more granular, you can configure different rate limits for different endpoints in AddRateLimiter() as well:

            // Write your code to configure the middleware here (rate limiting policies)

            // Add specific rate limiting policies
            rateLimiterOptions.AddFixedWindowLimiter(policyName: "fixed1", options =>
            {
                options.PermitLimit = 2;
                options.Window = TimeSpan.FromSeconds(10);
                options.AutoReplenishment = true;
            });
            
            rateLimiterOptions.AddFixedWindowLimiter(policyName: "fixed2", options =>
            {
                options.PermitLimit = 5;
                options.Window = TimeSpan.FromSeconds(10);
                options.AutoReplenishment = true;
            });

In the code snippet above, we have configured 2 fixed window limiters with different settings, and different policy names ("fixed1" and "fixed2"). We can apply these policies to specific endpoints within Umbraco using the same UmbracoPipelineFilter:

                    // Applying EnableRateLimitingAttribute to specific endpoint
                    postRouting.Use(async (context, next) =>
                    {
                        // Limit specific controller(s)
                        var controllerName = ControllerExtensions.GetControllerName<AuthenticationController>();
                        var actionName = nameof(AuthenticationController.PostRequestPasswordReset);

                        var currentEndpoint = context.GetEndpoint();
                        var actionDescriptor = currentEndpoint?.Metadata.GetMetadata<ControllerActionDescriptor>();

                        // Apply rate limiting logic based on your conditions
                        if (currentEndpoint is not null &&
                            actionDescriptor is not null &&
                            actionDescriptor.ControllerName == controllerName &&
                            actionDescriptor.ActionName == actionName)
                        {
                            // Apply rate limiting logic based on your conditions
                            
                            // Add Attribute to endpoint's metadata
                            var endpointMetadataCollection = new EndpointMetadataCollection(
                                new List<object>(currentEndpoint.Metadata)
                                {
                                    new EnableRateLimitingAttribute("fixed1")
                                });

                            // Update endpoint
                            var updatedEndpoint = new Endpoint(
                                currentEndpoint.RequestDelegate,
                                endpointMetadataCollection,
                                currentEndpoint.DisplayName);

                            context.SetEndpoint(updatedEndpoint);
                        }

                        await next.Invoke();
                    });

This part of the code shows how to apply the fixed1 policy to the AuthenticationController.PostRequestPasswordReset endpoint, responsible for handling password reset requests. We can do that by dynamically modifying the endpoint's metadata - attaching the EnableRateLimitingAttribute with the name of the policy which needs to be applied. This enables us to enforce the defined rate limits on a particular endpoint.

For your reference, here is the complete ApiRateLimiterComposer.cs implementation.

using System.Threading.RateLimiting;
using Microsoft.AspNetCore.Mvc.Controllers;
using Microsoft.AspNetCore.RateLimiting;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Web.BackOffice.Controllers;
using Umbraco.Cms.Web.Common.ApplicationBuilder;

namespace Umbraco.Docs.Samples;

public class ApiRateLimiterComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        // Register the rate limiting services
        builder.Services.AddRateLimiter(rateLimiterOptions =>
        {
            // Default is 503 (Service Unavailable)
            rateLimiterOptions.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

            // Use GlobalLimiter for all requests
            // rateLimiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
            // {
            //     return RateLimitPartition.GetFixedWindowLimiter(
            //         partitionKey: httpContext.Request.Headers.Host.ToString(),
            //         partition => new FixedWindowRateLimiterOptions
            //         {
            //             PermitLimit = 2,
            //             Window = TimeSpan.FromSeconds(10),
            //             AutoReplenishment = true
            //         });
            // });

            // Add specific rate limiting policies
            rateLimiterOptions.AddFixedWindowLimiter(policyName: "fixed1", options =>
            {
                options.PermitLimit = 2;
                options.Window = TimeSpan.FromSeconds(10);
                options.AutoReplenishment = true;
            });
            
            rateLimiterOptions.AddFixedWindowLimiter(policyName: "fixed2", options =>
            {
                options.PermitLimit = 5;
                options.Window = TimeSpan.FromSeconds(10);
                options.AutoReplenishment = true;
            });
        });

        builder.Services.Configure<UmbracoPipelineOptions>(options =>
        {
            options.AddFilter(new UmbracoPipelineFilter("UmbracoApiRateLimiter")
            {
                PostRouting = postRouting =>
                {
                    // Applying EnableRateLimitingAttribute to specific endpoint
                    postRouting.Use(async (context, next) =>
                    {
                        // Limit specific controller(s)
                        var controllerName = ControllerExtensions.GetControllerName<AuthenticationController>();
                        var actionName = nameof(AuthenticationController.PostRequestPasswordReset);

                        var currentEndpoint = context.GetEndpoint();
                        var actionDescriptor = currentEndpoint?.Metadata.GetMetadata<ControllerActionDescriptor>();
                        
                        // Apply rate limiting logic based on your conditions
                        if (currentEndpoint is not null &&
                            actionDescriptor is not null &&
                            actionDescriptor.ControllerName == controllerName &&
                            actionDescriptor.ActionName == actionName)
                        {   
                            // Add EnableRateLimiting attribute to endpoint's metadata
                            var endpointMetadataCollection = new EndpointMetadataCollection(
                                new List<object>(currentEndpoint.Metadata)
                                {
                                    new EnableRateLimitingAttribute("fixed1")
                                });

                            // Update endpoint
                            var updatedEndpoint = new Endpoint(
                                currentEndpoint.RequestDelegate,
                                endpointMetadataCollection,
                                currentEndpoint.DisplayName);

                            context.SetEndpoint(updatedEndpoint);
                        }

                        await next.Invoke();
                    });

                    // Apply the RateLimitingMiddleware
                    // Must be called after UseRouting()
                    postRouting.UseRateLimiter();
                }
            });
        });
    }
}

There is one default admin user in any Umbraco installation. This is the first user of the system.

Step one: Clear the connection string status in configuration

The first step is to clear the connection string to the database in the configuration. This is done to trigger the installation wizard.

That means that in your appsettings configuration files it should look like this:

{
  "ConnectionStrings": {
    "umbracoDbDSN": ""
  }
}

Step Two: Run the installer

If you now open your browser and surf to the website, you will see that the installer launches. Enter your new details, and use the original connection string. You are good to go.

The BackOfficeUserManager is the ASP.NET Core Identity UserManager implementation in Umbraco. It exposes APIs for working with Umbraco Users via the ASP.NET Core Identity including password handling.

Extending

The BackOfficeUserManager can be replaced during startup in order to use your own implementation. This may be required if you want to extend the functionality of the BackOfficeUserManager for things like supporting two-factor authentication(2FA).

Example

You can replace the BackOfficeUserManager in the startup class by using the SetBackOfficeUserManager extension on the IUmbracoBuilder.

builder.CreateUmbracoBuilder()
    .AddBackOffice()
    .AddWebsite()
    .AddDeliveryApi()
    .AddComposers()
    .SetBackOfficeUserManager<CustomBackOfficeUserManager>()
    .Build();

You can then implement your custom BackOfficeUserManager, like this. Note the constructor minimum needs to inject what is required for the base BackOfficeUserManager class:

 public class CustomBackOfficeUserManager : BackOfficeUserManager
{
    public CustomBackOfficeUserManager(
        IIpResolver ipResolver,
        IUserStore<BackOfficeIdentityUser> store,
        IOptions<BackOfficeIdentityOptions> optionsAccessor,
        IPasswordHasher<BackOfficeIdentityUser> passwordHasher,
        IEnumerable<IUserValidator<BackOfficeIdentityUser>> userValidators,
        IEnumerable<IPasswordValidator<BackOfficeIdentityUser>> passwordValidators,
        BackOfficeErrorDescriber errors,
        IServiceProvider services,
        IHttpContextAccessor httpContextAccessor,
        ILogger<CustomBackOfficeUserManager> logger,
        IOptions<UserPasswordConfigurationSettings> passwordConfiguration,
        IEventAggregator eventAggregator,
        IBackOfficeUserPasswordChecker backOfficeUserPasswordChecker)
        : base(
            ipResolver,
            store,
            optionsAccessor,
            passwordHasher,
            userValidators,
            passwordValidators,
            errors,
            services,
            httpContextAccessor,
            logger,
            passwordConfiguration,
            eventAggregator,
            backOfficeUserPasswordChecker)
    {
    }

    //Override whatever you need, e.g. SupportsUserTwoFactor.
    public override bool SupportsUserTwoFactor => false;
}

Notifications

There are many notifications you can handle on the BackOfficeUserManager. Internally these are mainly used for auditing but there are some that allow you to customize some workflows:

• SendEmailNotification

  • This is a generic notification but it has a property EmailType that specify the email type. This type can be UserInvite. In that case, it allows you to take control over how a user in the backoffice is invited. This might be handy if you are using an External Login Provider that has the DenyLocalLogin option assigned and you still want to have the user invite functionality available. In this setup, all of your users are controlled by your external login provider so you would need to handle the user invite flow yourself by using this event and inviting the user via your external provider. If you are using this event to replace the default functionality you will need to tell Umbraco that you've handled the invite by calling the SendEmailNotification.HandleEmail() method.)

• UserLogoutSuccessNotification

  • This is specifically used if you have an External Login Provider in use and you want to log out of that external provider when the user is logged out of the backoffice (that is log out of everywhere). The notification has a property SignOutRedirectUrl. If this property is assigned then Umbraco will redirect to that URL upon successful backoffice sign out in order to sign the user out of the external login provider.

Here you find some tips and trick for hardening the security of your Umbraco installation.

Lock down access to your Umbraco folder (IIS)

It’s considered a good practice to lock down the Umbraco folder to specific IP addresses and/or IP ranges to ensure this folder is not available to everyone.

The prerequisite of this to work is that you’re using IISRewrite

If you’ve made sure that you’ve installed this on your server we can start locking down our Umbraco folder. This can be down by following these three steps.

1. We are going to lock down /Umbraco/, but because API-controllers and Surface-controller will use the path /umbraco/api/ and /umbraco/surface/ these will also be locked down. Our first rule in the IISRewrite.config will be used to make sure that these are not locked by IP-address.

<rule name="Ignore" stopProcessing="true">
    <match url="^(?:umbraco/api|umbraco/surface)/" />
    <action type="None" />
</rule>

Some older versions of Umbraco also relied on /umbraco/webservices/ for loadbalancing purposes. If you're loadbalancing you should also add umbraco/webservices to the rule.

<rule name="Ignore" stopProcessing="true">
    <match url="^(?:umbraco/api|umbraco/surface|umbraco/webservices)/" />
    <action type="None" />
</rule>

1. Get the IP-addresses of your client and write these down like a regular expression. If the IP-addresses are for example 213.3.10.8 and 88.4.43.108 the regular expression would be "213.3.10.8|88.4.43.108".

2. Lock down the Umbraco folder by putting this rule into your IISRewrite-rules

<rule name="Allowed IPs" stopProcessing="true">
    <match url="^(?:umbraco)(?:/|$)" />
    <conditions>
        <add input="{REMOTE_ADDR}" negate="true" pattern="213.3.10.8|88.4.43.108" />
    </conditions>
    <action type="AbortRequest" />
</rule>

If you now go to /umbraco/ from a different IP-address the login screen will not be rendered.

Password settings

The settings for Umbraco passwords are configurable in appsettings. There are two different configuration objects - One for Umbraco Members and one for Users.

For more information see the Security Settings documentation.

Password reset settings

Umbraco backend users can reset their own password, or if they try too much, have a locked out account.

To deactivate the User password reset look at the Umbraco Settings Security section.

To configure password reset verify the Backoffice Login Password Reset section.

Other security settings

• The Umbraco timeout in minutes

• disableAlternativeTemplates If set to false this can be used to try to render pages in a way that they are not supposed to

• disableFindContentByIdPath If set to false this can be used to do an enumeration of the nodes in your website and find hidden pages.

• Umbraco Forms: AntiForgeryToken and DisableFormCaching

Having the ability to replace the logic to validate a username and password against a custom data store is important to some developers. Normally in ASP.Net Core Identity this would require you to override the UmbracoBackOfficeUserManager.CheckPasswordAsync implementation and then replace the UmbracoBackOfficeUserManager with your own class during startup. Since this is a common task we've made this process a lot easier with an interface called IBackOfficeUserPasswordChecker.

Here are the steps to specify your own logic for validating a username and password for the backoffice:

1. Create an implementation of Umbraco.Cms.Core.Security.IBackOfficeUserPasswordChecker

   • There is one method in this interface: Task<BackOfficeUserPasswordCheckerResult> CheckPasswordAsync(BackOfficeIdentityUser user, string password);

   • The result of this method can be 3 things:

     • ValidCredentials = The credentials entered are valid and the authorization should proceed

     • InvalidCredentials = The credentials entered are not valid and the authorization process should return an error

     • FallbackToDefaultChecker = This is an optional result which can be used to fallback to Umbraco's default authorization process if the credentials could not be verified by your own custom implementation

   For example, to always allow login when the user enters the password test you could do:

   Copy

   using System.Threading.Tasks;
   using Umbraco.Core.Models.Identity;
   using Umbraco.Core.Security;
   
   namespace MyNamespace;
   
   public class MyPasswordChecker : IBackOfficeUserPasswordChecker
   {
       public Task<BackOfficeUserPasswordCheckerResult> CheckPasswordAsync(BackOfficeIdentityUser user, string password)
       {
           var result = (password == "test")
               ? Task.FromResult(BackOfficeUserPasswordCheckerResult.ValidCredentials)
               : Task.FromResult(BackOfficeUserPasswordCheckerResult.InvalidCredentials);
   
           return result;
       }
   }

2. Register the MyPasswordChecker in your Program.cs file:

   Copy

   builder.CreateUmbracoBuilder()
   .AddBackOffice()
   .AddWebsite()
   .AddDeliveryApi()
   .AddComposers()
   .Build();
   
   builder.Services.AddUnique<IBackOfficeUserPasswordChecker, MyPasswordChecker>();

The cookies listed in this article are required only for accessing the Backoffice. You can include these in your own cookie policy, if you wish.

Necessary Cookies

The below cookies are necessary for accessing the Umbraco Backoffice and functioning of the website. They allow you to enjoy the contents and services you request.

The UMB_SESSION cookie is secure if you are using HTTPS pages. However, if you wish to secure the cookie in your code, add the following in the Program.cs file after Build();

builder.Services.AddSession(options =>
    {
        options.Cookie.Name = "UMB_SESSION";
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });

For information on the rest of the cookies, see the Constants-Web.cs file on Github.

Both the Umbraco backoffice users and website members support external login providers (OAuth) for performing authentication. This could be any OpenIDConnect provider such as Entra ID/Azure Active Directory, Identity Server, Google, or Facebook.

Install an appropriate Nuget package for the provider you wish to use. Some popular ones found in Nuget include:

• Google

• Facebook

• Microsoft

• Twitter

• Open ID Connect

• Others

Try it out

Extend core functionality

When you are implementing your own custom authentication on Users and/or Members on your Umbraco CMS website, you are effectively extending existing features.

The process requires adding a couple of new classes (.cs files) to your Umbraco project:

• Custom-named configuration to add additional configuration for handling different options related to the authentication. See a generic example of the configuration class to learn more.

• A composer and named to extend on the default authentication implementation in Umbraco CMS for either Users or Members. See a generic example to learn more.

You can setup similar behavior using a static extension class and add them straight into the Program.cs file. But you will lose access to dependency injection this way, thus our helper class.

Auto-linking

Traditionally, a backoffice User or frontend Member will need to exist in Umbraco first. Once they exist there, they can link their user account to an external login provider.

In many cases, however, the external login provider you install will be the source of truth for all of your users and members.

In this case, you will want to provide a Single Sign On (SSO) approach to logging in. This would enable the creation of user accounts on the external login provider and then automatically give them access to Umbraco. This is called auto-linking.

Local logins

When auto-linking is configured, then any auto-linked user or member will have an empty password assigned. This means that they will not be able to log in locally (via username and password). In order to log in locally, they will have to assign a password to their account in the backoffice or the edit profile page.

For users specifically, if the DenyLocalLogin option is enabled, all password-changing functionality in the backoffice is disabled, and local login is not possible.

Transferring Claims from External identities

In some cases, you may want to flow a Claim returned in your external login provider to the Umbraco backoffice identity's Claims. This could be the authentication cookie. Flowing Claims between the two can be done during the OnAutoLinking and OnExternalLogin.

The reason for wanted to flow a Claim could be to store the external login provider user ID into the backoffice identity cookie. It can then be retrieved on each request to look up data in another system needing the current user ID from the external login provider.

Example

This is a simplistic example of brevity including no null checks, etc.

OnAutoLinking = (user, loginInfo) => {
    // You can customize the user before it's linked.
    // i.e. Modify the user's groups based on the Claims returned
    // in the externalLogin info
    var extClaim = externalLogin
        .Principal
        .FindFirst("MyClaim");
    user.Claims.Add(new IdentityUserClaim<string>
    {
        ClaimType = extClaim.Type,
        ClaimValue = extClaim.Value,
        UserId = user.Id
    });
},
OnExternalLogin = (user, loginInfo) => {
    // You can customize the user before it's saved whenever they have
    // logged in with the external provider.
    // i.e. Sync the user's name based on the Claims returned
    // in the externalLogin info
    var extClaim = externalLogin
        .Principal
        .FindFirst("MyClaim");
    user.Claims.Add(new IdentityUserClaim<string>
    {
        ClaimType = extClaim.Type,
        ClaimValue = extClaim.Value,
        UserId = user.Id
    });
    return true;
}

Storing external login provider data

In some cases, you may need to persist data from your external login provider like Access Tokens, etc.

You can persist this data to the affiliated user's external login data via the IExternalLoginWithKeyService. The void Save(Guid userOrMemberKey,IEnumerable<IExternalLoginToken> tokens) overload takes a new model of type IEnumerable<IExternalLogin>.

IExternalLogin contains a property called UserData. This is a blob text column which can store any arbitrary data for the external login provider.

Auto-linking on backoffice authentication

For some providers, it does not make sense to use auto-linking. This is especially true for public providers such as Google or Facebook.

In those cases, it would mean that anyone who has a Google or Facebook account can log into your site.

If auto-linking for public providers such as these was needed you would need to limit the access. This can be done by domain or other information provided in the claims using the options/callbacks specified in those provider's authentication options.

Is your project hosted on Umbraco Cloud?

Umbraco Cloud uses Umbraco ID for all authentication, including access to the Umbraco Backoffice.

If you are working with External Login Providers on a project hosted on Umbraco Cloud, extra configuration is required.

To disable the automatic redirect to Umbraco ID, follow these steps:

1. Open the umbraco-cloud.json file in your favorite code editor.

2. Locate the Identity section.

3. Add a new key: AutoRedirectLogin.

4. Set the value to false.

"Identity": {
    "ClientId": "0297c0f6-83ad-4481-9ae2-07a3f5475333",
    "ClientSecret": "Q5~T526ixOHlj47lg7Mu7_.zN1fK.7ua.9",
    "EnvironmentId": "3105e6eb-4a1e-42dd-91e9-ffdbe3dd30a8",
    "LocalLoginRedirectUri": "https://redirect.identity.umbraco.com",
    "AutoRedirectLogin": false
  }

Auto-linking on Member authentication

Auto-linking on Member authentication only makes sense if you have a public member registration already or the provider does not have public account creation.

Generic examples

The following section presents a series of generic examples.

Custom-named configuration

The configuration file is used to configure a handful of different options for the authentication setup. A generic example of such file is shown below.

using Microsoft.Extensions.Options;
using Umbraco.Cms.Core;
using Umbraco.Cms.Web.BackOffice.Security;

namespace MyUmbracoProject.CustomAuthentication;

public class GenericBackOfficeExternalLoginProviderOptions : IConfigureNamedOptions<BackOfficeExternalLoginProviderOptions>
{
    public const string SchemeName = "Generic";
    public void Configure(string name, BackOfficeExternalLoginProviderOptions options)
    {
        if (name != Constants.Security.BackOfficeExternalAuthenticationTypePrefix + SchemeName)
        {
            return;
        }

        Configure(options);
    }

    public void Configure(BackOfficeExternalLoginProviderOptions options)
    {
        // The following options are relevant if you
        // want to configure auto-linking on the authentication.
        options.AutoLinkOptions = new ExternalSignInAutoLinkOptions(

            // Set to true to enable auto-linking
            autoLinkExternalAccount: true,

            // [OPTIONAL]
            // Default: "Editor"
            // Specify User Group.
            defaultUserGroups: new[] { Constants.Security.EditorGroupAlias },

            // [OPTIONAL]
            // Default: The culture specified in appsettings.json.
            // Specify the default culture to create the User as.
            // It can be dynamically assigned in the OnAutoLinking callback.
            defaultCulture: null,

            // [OPTIONAL]
            // Disable the ability to link/unlink manually from within
            // the Umbraco backoffice.
            // Set this to false if you don't want the user to unlink
            // from this external provider.
            allowManualLinking: false
        )
        {
            // [OPTIONAL] Callback
            OnAutoLinking = (autoLinkUser, loginInfo) =>
            {
                // Customize the user before it's linked.
                // Modify the User's groups based on the Claims returned
                // in the external login info.
            },

            // [OPTIONAL] Callback
            OnExternalLogin = (user, loginInfo) =>
            {
                // Customize the User before it is saved whenever they have
                // logged in with the external provider.
                // Sync the Users name based on the Claims returned
                // in the external login info

                // Returns a boolean indicating if sign-in should continue or not.
                return true;
            }
        };

    }
}

using Microsoft.Extensions.Options;
using Umbraco.Cms.Core;
using Umbraco.Cms.Web.Common.Security;

namespace MyUmbracoProject.CustomAuthentication;

public class ProviderMembersExternalLoginProviderOptions : IConfigureNamedOptions<MemberExternalLoginProviderOptions>
{
    public const string SchemeName = "OpenIdConnect";
    public void Configure(string? name, MemberExternalLoginProviderOptions options)
    {
        if (name != Constants.Security.MemberExternalAuthenticationTypePrefix + SchemeName)
        {
            return;
        }

        Configure(options);
    }

    public void Configure(MemberExternalLoginProviderOptions options)
    {
        // The following options are relevant if you
        // want to configure auto-linking on the authentication.
        options.AutoLinkOptions = new MemberExternalSignInAutoLinkOptions(

            // Set to true to enable auto-linking
            autoLinkExternalAccount: true,

            // [OPTIONAL]
            // Default: The culture specified in appsettings.json.
            // Specify the default culture to create the Member as.
            // It can be dynamically assigned in the OnAutoLinking callback.
            defaultCulture: null,

            // [OPTIONAL]
            // Specify the default "IsApproved" status.
            // Must be true for auto-linking.
            defaultIsApproved: true,

            // [OPTIONAL]
            // Default: "Member"
            // Specify the Member Type alias.
            defaultMemberTypeAlias: Constants.Security.DefaultMemberTypeAlias
        )
        {
            // [OPTIONAL] Callback
            OnAutoLinking = (autoLinkUser, loginInfo) =>
            {
                // Customize the Member before it's linked.
                // Modify the Members groups based on the Claims returned
                // in the external ogin info.
            },
            OnExternalLogin = (user, loginInfo) =>
            {
                // Customize the Member before it is saved whenever they have
                // logged in with the external provider.
                // Sync the Members name based on the Claims returned
                // in the external login info

                // Returns a boolean indicating if sign-in should continue or not.
                return true;
            }
        };
    }
}

Next, you need to register the button in the BackOffice. This is done by adding a manifest file to the App_Plugins/ExternalLoginProviders folder.

{
  "$schema": "../../umbraco-package-schema.json",
  "name": "My Auth Package",
  "allowPublicAccess": true,
  "extensions": [
    {
      "type": "authProvider",
      "alias": "My.AuthProvider.Generic",
      "name": "My Auth Provider",
      "forProviderName": "Umbraco.Generic",
      "meta": {
        "label": "Generic",
        "defaultView": {
          "icon": "icon-cloud"
        },
        "behavior": {
          "autoRedirect": false
        },
        "linking": {
          "allowManualLinking": true
        }
      }
    }
  ]
}

You have a few options to configure the button:

• element - Define your own custom element for the button. This is useful if you want to display something other than a button, For example: a link or an image. For more information, see the Customizing the BackOffice Login Button section.

• forProviderName - The name of the provider you are configuring. This should match the SchemeName in the GenericBackOfficeExternalLoginProviderOptions class with "Umbraco." prepended.

• meta.label - The label to display on the button. The user will see this text. For example: "Sign in with Generic".

• meta.defaultView.icon - The icon to display on the button. You can use any of the icons from the Umbraco Icon Picker. If you want to use a custom icon, you need to first register it to the icons extension point.

• meta.defaultView.color - (Default: "secondary") The color of the button. You can use any of the colors from the Umbraco UI Library.

• meta.defaultView.look - (Default: "default") The look of the button. You can use any of the looks from the Umbraco UI Library.

• meta.behavior.autoRedirect - Automatically redirects the user to the external login provider, skipping the Umbraco login page, unless the user has specifically logged out or timed out.

• meta.behavior.popupTarget - (Default: "umbracoAuthPopup") The target for the popup window. This is the name of the window that will be opened when the user clicks the button. If you want to open the login page in a new tab, you can set this to "_blank".

• meta.behavior.popupFeatures - (Default: "width=600,height=600,menubar=no,location=no,resizable=yes,scrollbars=yes,status=no,toolbar=no") The features of the popup window. This is a string of comma-separated key-value pairs. For example: "width=600,height=600". You can read more on the MDN Web Docs.

• meta.linking.allowManualLinking - Allows the user to link or unlink their account from the BackOffice. You need to allow manual linking on the ExternalSignInAutoLinkOptions as well.

The button will now be displayed on the login page in the Umbraco Backoffice.

Generic backoffice login provider composer

A composer and genericAuthenticationOptions configuration class to setup the authentication options for the generic authentication provider using dependency injection. Replace genericAuthenticationOptions with the Options method from the provider you are using.

// this example uses a non existing generic OathProvider NuGet package
// but any package that uses the Microsoft.AspNetCore.Authentication.OAuth.OathOptions will work
using AspNet.Security.OAuth.Generic;
using Microsoft.Extensions.Options;
using Umbraco.Cms.Api.Management.Security;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Web.Common.Helpers;

namespace MyUmbracoProject.CustomAuthentication;

public class GenericBackOfficeExternalLoginComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        // register the generic loginProvider options (auto linking, manual linking, ...)
        builder.Services.ConfigureOptions<GenericBackOfficeExternalLoginProviderOptions>();
        // register the generic authtication options (secret, callback, errorhandling, ...)
        builder.Services.ConfigureOptions<ConfigureGenericAuthenticationOptions>();

        builder.AddBackOfficeExternalLogins(logins =>
        {
            logins.AddBackOfficeLogin(
                backOfficeAuthenticationBuilder =>
                {
                    // this Add... method will be part of the OathProvider nuget package you install
                    backOfficeAuthenticationBuilder.AddGenericProvider(
                    // replace AddGenericProvider with the Add method of the provider you are using
                        BackOfficeAuthenticationBuilder.SchemeForBackOffice(GenericBackOfficeExternalLoginProviderOptions
                            .SchemeName)!,
                        options =>
                        {
                            // need to give an empty action here for the options pattern configuration to work 🤷
                            // if you do not wish to use the umbraco default error handling and hardcode all your values instead of injecting them,
                            // you can set the configuration right here instead.
                        });
                });
        });
    }
}

// the ...AuthenticationOptions method will be part of the OathProvider nuget package you install
// check the Add... method invoked on the backOfficeAuthenticationBuilder to figure out the correct type
public class ConfigureGenericAuthenticationOptions : IConfigureNamedOptions<GenericAuthenticationOptions>
{
    private readonly OAuthOptionsHelper _helper;

    public ConfigureGenericAuthenticationOptions(OAuthOptionsHelper helper)
    {
        _helper = helper;
    }

    public void Configure(GenericAuthenticationOptions options)
    {
        // since we have access to dependency injection, these values can be read from the app settings using the IOptions pattern
        options.CallbackPath = "/umbraco-signing-generic"; // can be anything as middleware will add this to the route table
        options.ClientId = "your client id for the login provider";
        options.ClientSecret = "your client secret for the login provider";
        options.Scope.Add("user:email"); // email is needed for auto linking purposes

        // This will redirect error responses from the login provider towards the default umbraco oath login error page
        // which will try to display the error state in a meaningful way.
        // You can implement your own error handling by handling options.Events.OnAccessDenied & options.Events.OnRemoteFailure
        _helper.SetDefaultErrorEventHandling(options, GenericBackOfficeExternalLoginProviderOptions.SchemeName);
    }

    public void Configure(string? name, GenericAuthenticationOptions options)
    {
        // only configure the options if it is for the backend
        if (name == BackOfficeAuthenticationBuilder.SchemeForBackOffice(GenericBackOfficeExternalLoginProviderOptions
                .SchemeName))
        {
            Configure(options);
        }
    }
}

Static extension class

The extension class is required to extend on the default authentication implementation in Umbraco CMS. A generic example of such extension class can be seen below.

using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Extensions;
using Umbraco.Cms.Web.BackOffice.Security;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Configuration;

namespace MyUmbracoProject.CustomAuthentication;

public static class GenericBackofficeAuthenticationExtensions
{
    public static IUmbracoBuilder AddGenericBackofficeAuthentication(this IUmbracoBuilder builder)
    {
        // Register ProviderBackOfficeExternalLoginProviderOptions here rather than require it in startup
        builder.Services.ConfigureOptions<GenericBackOfficeExternalLoginProviderOptions>();

        builder.AddBackOfficeExternalLogins(logins =>
        {
            logins.AddBackOfficeLogin(
                backOfficeAuthenticationBuilder =>
                {
                    // The scheme must be set with this method to work for the back office
                    // Replace GenericOfficeExternalLoginProviderOptions with the Options method from the provider you are using
                    var schemeName =
                        backOfficeAuthenticationBuilder.SchemeForBackOffice(GenericOfficeExternalLoginProviderOptions
                            .SchemeName);

                    ArgumentNullException.ThrowIfNull(schemeName);

                    // Replace AddGenericProvider with the Add method from the provider you are using

                    backOfficeAuthenticationBuilder.AddGenericProvider(
                        schemeName,
                        options =>
                        {
                            // Callback path: Represents the URL to which the browser should be redirected to.
                            // The default value is '/signin-provider'.
                            // The value here should match what you have configured in you external login provider.
                            // The value needs to be unique.
                            options.CallbackPath = "/umbraco-provider-signin";
                            options.ClientId = "YOURCLIENTID"; // Replace with your client id generated while creating OAuth client ID
                            options.ClientSecret = "YOURCLIENTSECRET"; // Replace with your client secret generated while creating OAuth client ID

                            // Example: Map Claims
                            // Relevant when using auto-linking.
                            options.GetClaimsFromUserInfoEndpoint = true;
                            options.TokenValidationParameters.NameClaimType = "name";

                            // Example: Add scopes
                            options.Scope.Add("email");
                        });
                });
        });
        return builder;
    }
}

using Microsoft.Extensions.DependencyInjection;
using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Extensions;

namespace MyUmbracoProject.CustomAuthentication;

public static class ProviderMemberAuthenticationExtensions
{
    public static IUmbracoBuilder AddProviderMemberAuthentication(this IUmbracoBuilder builder)
    {
        // [OPTIONAL]
        // Register ProviderMembersExternalLoginProviderOptions here rather than require it in startup
        builder.Services.ConfigureOptions<ProviderMembersExternalLoginProviderOptions>();

        builder.AddMemberExternalLogins(logins =>
        {
            logins.AddMemberLogin(
                memberAuthenticationBuilder =>
                {
                    memberAuthenticationBuilder.AddProvider(
                        // The scheme must be set with this method to work for the back office
                        memberAuthenticationBuilder.SchemeForMembers(ProviderMembersExternalLoginProviderOptions.SchemeName),
                        options =>
                        {
                            // Callback path: Represents the URL to which the browser should be redirected to.
                            // The default value is `/signin-oidc`.
                            // The value here should match what you have configured in your external login provider.
                            // The value needs to be unique.
                            options.CallbackPath = "/umbraco-provider-signin";

                            options.ClientId = "YOURCLIENTID";
                            options.ClientSecret = "YOURCLIENTSECRET";

                                // Example: Save login tokens
                            options.SaveTokens = true;

                        });
                });
        });
        return builder;
    }
}

For a more in-depth article on how to set up OAuth providers in .NET refer to the Microsoft Documentation.

Customizing the BackOffice Login Button

If you want to customize the login button, you can do so by adding a custom element to the manifest file. This is useful if you want to display something other than a button. For example, a link or an image.

The path to the custom view is a virtual path, like this example: "~/App_Plugins/MyPlugin/BackOffice/my-external-login.js".

When a custom view is specified, it is 100% up to this module to perform all the required logic.

The module should define a Custom Element and export it as default. Optionally, the Custom Element can declare a number of properties to be passed to it. These properties are:

• manifest: The manifest object for the provider that you registered in the umbraco-package.json file.

• onSubmit: A function that is called when the form is submitted. This function will handle the form submission and redirect the user to the external login provider.

• userLoginState: The current view state of the user. This can be one of the following values:

  • loggingIn: The user is on the login screen.

  • loggedOut: The user clicked the logout button and is on the logged-out screen.

  • timedOut: The user's session has timed out and they are on the timed-out screen.

TypeScript

If you use TypeScript, you can use this interface to define the properties:

type UserViewState = 'loggingIn' | 'loggedOut' | 'timedOut';

interface IExternalLoginCustomViewElement {
  displayName?: string;
  providerName?: string;
  externalLoginUrl?: string;
  userViewState?: UserViewState;
};

Examples

The Custom Element can be implemented in a number of ways with many different libraries or frameworks. The following examples show how to make a button appear and redirect to the external login provider. You will learn how to use the externalLoginUrl property to redirect to the external login provider. The login form should look like this when you open Umbraco:

When you click the button, the form will submit a POST request to the externalLoginUrl property. The external login provider will then redirect back to the Umbraco site with the user logged in.

{
  "$schema": "../../umbraco-package-schema.json",
  "name": "My Auth Package",
  "allowPublicAccess": true,
  "extensions": [
    {
      "type": "authProvider",
      "alias": "My.AuthProvider.Generic",
      "name": "My Auth Provider",
      "forProviderName": "Umbraco.Generic",
      "element": "/App_Plugins/ExternalLoginProviders/my-external-login.js", // This line has been added
      "meta": {
        "label": "Generic",
        "defaultView": {
          "icon": "icon-cloud"
        },
        "behavior": {
          "autoRedirect": false
        },
        "linking": {
          "allowManualLinking": true
        }
      }
    }
  ]
}

const template = document.createElement('template');
template.innerHTML = `
  <style>
    :host {
      display: block;
      width: 100%;
    }
    #button {
      width: 100%;
    }
  </style>
  <h3>Our Company</h3>
  <p>If you have signed up with Our Company, you can sign in to Umbraco by clicking the button below.</p>
  <uui-button type="button" id="button" look="primary">
    <uui-icon name="icon-cloud"></uui-icon>
    Sign in with Our Company
  </uui-button>
`;

/**
 * This is an example how to set up a custom element as a Web Component.
 */
export default class MyCustomView extends HTMLElement {
  manifest = {};
  onSubmit = () => {};
  userLoginState = '';

  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.appendChild(template.content.cloneNode(true));

    this.shadowRoot.getElementById('button').addEventListener('click', () => {
      this.onSubmit(this.manifest.forProviderName);
    });
  }
}

customElements.define('my-custom-view', MyCustomView);

import { LitElement, css, html } from 'https://cdn.jsdelivr.net/gh/lit/dist@3/core/lit-core.min.js';

/**
 * This is an example how to set up a LitElement component.
 */
export default class MyLitView extends LitElement {
  static get properties() {
    return {
      manifest: { type: Object },
      onSubmit: { type: Function },
      userLoginState: { type: String, state: true }
    };
  }

  get displayName() {
    return this.manifest.meta?.label ?? this.manifest.forProviderName;
  }

  render() {
    return html`
        <h3>Our Company</h3>
        <p>If you have an account with Our Company, you can sign in to Umbraco by clicking the button below.</p>
        <p>The user is currently: ${this.userLoginState}</p>
        <uui-button type="button" id="button" look="primary" label="${this.displayName}" @click=${() => this.onSubmit(this.manifest.forProviderName)}>
          <uui-icon name="icon-cloud"></uui-icon>
          ${this.displayName}
        </uui-button>
    `;
  }

  static styles = css`
    :host {
      display: block;
      width: 100%;
    }
    #button {
      width: 100%;
    }
  `;
}

customElements.define('my-lit-view', MyLitView);

We highly encourage the use of HTTPS on Umbraco websites especially in production environments. By using HTTPS you greatly improve the security of your website.

There are multiple benefits of HTTPS:

• Trust - when your site is delivered over HTTPS your users will see that your site is secured, they are able to view the certificate assigned to your site and know that your site is legitimate

• Removing an attack vector called "Man in the middle" (or network Sniffing)

• Guards against Phishing, an attacker will have a hard time obtaining an authentic Secure Sockets Layer (SSL) certificate

• Google likes HTTPS, it may help your site's rankings

Another benefits of HTTPS is that you are able to use the http2 protocol if your web server and browser support it.

Set UseHttps configuration option

Umbraco allows you to force HTTPS for all backoffice communications by using the following configuration:

In Umbraco 9, set the UseHttps key in appSettings to true.

{
    "Umbraco": {
        "CMS": {
            "Global": {
                "UseHttps": true
            }
        }
    }
}

This options does multiple things when it is turned on:

• Ensures that the backoffice authentication cookie is set to secure only (so it can only be transmitted over https)

• All non-https requests to any backoffice controller are redirected to https

• All self delivered Umbraco requests are performed over https

• All Umbraco notification emails with links generated have https links

• All authorization attempts for backoffice handlers and services will be denied if the request is not over https

Redirect traffic in code

The .NET5+ way to handle this, is by adding this HttpsRedirectionMiddleware to your pipeline in Program.cs. This can be done by adding app.UseHttpsRedirection(); before the call to app.UseUmbraco() in the Configure method:

app.UseHttpsRedirection();

    app.UseUmbraco()
        .WithMiddleware(u =>
        {
            u.UseBackOffice();
            u.UseWebsite();
        })
        .WithEndpoints(u =>
        {
            u.UseBackOfficeEndpoints();
            u.UseWebsiteEndpoints();
        });

Redirect traffic on IIS

Once you enable HTTPS for your site you should redirect all requests to your site to HTTPS. This can be done with an IIS rewrite rule. The IIS rewrite module needs to be installed for this to work, most hosting providers will have that enabled by default.

In your web.config find or add the <system.webServer><rewrite><rules> section and put the following rule in there. This rule will redirect all requests for the site http://mysite.com URL to the secure https://mysite.com URL and respond with a permanent redirect status.

<rule name="HTTP to HTTPS redirect" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
        <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
    </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>

SSL versus Transport Layer Security (TLS)

In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS), or, formerly, its predecessor, Secure Sockets Layer (SSL) - wikipedia

While the deprecated SSL (2.0 and 3.0) are not supported anymore by modern browsers, some of the Umbraco configuration still uses SSL. But rest assured, that is only the name.

In this article, you will find everything you need regarding security within Umbraco.

The Umbraco Trust Center (external)

On our main website, we have a dedicated security section which provides all the details you need to know about security within the Umbraco CMS. This includes how to report a vulnerability.

Secure Sockets Layer (SSL)/HTTPS

We highly encourage the use of HTTPS on Umbraco websites, especially in production environments. By using HTTPS you greatly improve the security of your website.

In the "Use HTTPS" article you can learn more about how to use HTTPS and how to set it up.

Security Settings

Learn which password settings that can be configured in Umbraco.

Security Hardening

Learn about how to harden the security on your Umbraco website to secure it even further.

Security on Umbraco Cloud

When your project is hosted on Umbraco Cloud, you might be interested in more details about the security of the hosting. This information can be found in the Umbraco Cloud FAQs section of the documentation.

Backoffice users and website members (external)

Authentication for backoffice users and website members in Umbraco uses ASP.NET Core Identity which is a flexible and extendable framework for authentication.

Out of the box Umbraco ships with a custom ASP.NET Core Identity implementation which uses Umbraco's database data. Normally this is fine for most Umbraco developers, but in some cases the authentication process needs to be customized.

External login providers

The Umbraco users and members supports external login providers (OAuth) for performing authentication of your users/members. This could be any OpenIDConnect provider such as Entra ID/Azure Active Directory, Identity Server, Google or Facebook.

Two-factor authentication

The Umbraco members supports a two-factor authentication (2FA) abstraction for implementing a 2FA provider of your choice. This could be any Time-based One-time Password (TOTP) Algorithm, including Microsoft and Google Authenticator Apps

BackOfficeUserManager and Notifications

The BackOfficeUserManager is the ASP.NET Core Identity UserManager implementation in Umbraco. It exposes APIs for working with Umbraco Users via the ASP.NET Core Identity including password handling.

Custom password check

In most cases External login providers (OAuth) will meet the needs of most users when needing to authenticate with external resources. In some cases you may need to only change how the username and password credentials are checked.

This is typically a legacy approach to validating credentials with external resources but it is possible.

You are able to check the username and password against your own credentials store by implementing a IBackOfficeUserPasswordChecker.

Sensitive data on members

Marking fields as sensitive will hide the data in those fields for backoffice users that do not have permission to view personal data of members.

Learn more about this in the Sensitive Data article.

Setup Umbraco for a Federal Information Processing Standards (FIPS) Compliant Server

How to configure Umbraco to run on a FIPS compliant server.

Reset admin password

Use this guide to reset the password of the "admin" user.

If you need to reset accounts of every other user while you still have administrative action, check this "reset normal user password" article.

Other articles related to security

• Health Checks

Umbraco Training

Umbraco HQ offers a full-day training course covering an overview of Transport Layer Security (TLS), understanding threats, two-factor authentication, and more. The course targets frontend and backend developers, designers, and technical users.

Explore the Security Training Course to learn more about the topics covered and how it can enhance your Umbraco development skills.

This tutorial walks through configuring Umbraco and Lucene to be FIPS compliant and serve up websites on a server with FIPS enabled.

What is FIPS?

The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer security standard used to define approved cryptographic modules. The FIPS 140 standard also sets forth requirements for key generation and for key management.

Microsoft Windows has a "FIPS mode" of operation where it detects the cryptographic algorithms used by software running on it and will throw exceptions if it detects the use of non-FIPS compliant algorithms. Using MD5 hashing is generally the biggest culprit of issues running on FIPS enabled servers.

How can I test my site with FIPS enabled?

FIPS can be enabled through your Local Group Policy, Registry Setting, or Network Adapter setting. For more information about how to enable FIPS mode on Windows see this tutorial: How-to Enable FIPS on Windows

What version of Umbraco is FIPS compliant?

Umbraco 7.6.4+ has implemented checks for when FIPS mode is enabled on the server that it is installed on. When FIPS mode is detected, the cryptographic algorithms for hashing are changed to a FIPS compliant algorithm. When FIPS mode is disabled, then Umbraco uses backward compatible algorithms (MD5) so as not to affect existing installs. As of Umbraco version 7.6.4, the FIPS compliant cryptographic algorithm used is SHA1.

Umbraco 9.0.0 and key dependencies are FIPS compliant

Since Umbraco 9, the dependency to Lucene.NET is updated to version 4+. Thereby are both Umbraco and all key dependencies FIPS compliant.

FAQ

Can I install Umbraco directly on a version of Windows with FIPS mode enabled?

Installing to the FIPS server may not work. It's best to deploy an existing known working version to the FIPS server.

Sometimes it might be necessary to validate the contents of a file before it gets saved to disk when uploading trough the backoffice.

To help with this, Umbraco supplies a FileStreamSecurityValidator that runs all registered IFileStreamSecurityAnalyzer implementations on the file streams it receives from it's different file upload endpoints. When any of the analyzers deem the file to be unsafe, the endpoint disregards the file and shows a relevant validation message where appropriate. This all happens in memory before the stream is written to a temporary file location.

Implementing a FileStreamSecurityValidator

The IFileStreamSecurityAnalyzer needs a single method to be implemented:

• IsConsideredSafe: This method should return false if the analyzer finds a reason not to trust the file

Example FileStreamSecurityAnalyzer

The following class shows how one could potentially guard against Cross-site scripting(XSS) vulnerabilities in an svg file.

public class SvgXssSecurityAnalyzer : IFileStreamSecurityAnalyzer
    {
        public bool ShouldHandle(Stream fileStream)
        {
            // reduce memory footprint by partially reading the file
            var startBuffer = new byte[256];
            var endBuffer = new byte[256];
            fileStream.Read(startBuffer);
            if (endBuffer.Length > fileStream.Length)
                fileStream.Seek(0, SeekOrigin.Begin);
            else
                fileStream.Seek(fileStream.Length - endBuffer.Length, SeekOrigin.Begin);
            fileStream.Read(endBuffer);
            var startString = System.Text.Encoding.UTF8.GetString(startBuffer);
            var endString = System.Text.Encoding.UTF8.GetString(endBuffer);
            return startString.Contains("<svg")
                   && startString.Contains("xmlns=\"http://www.w3.org/2000/svg\"")
                   && endString.Contains("/svg>");
        }

        public bool IsConsideredSafe(Stream fileStream)
        {
            var streamReader = new StreamReader(fileStream); // do not use a using as this will dispose of the underlying stream
            var fileContent = streamReader.ReadToEnd();
            return !(fileContent.Contains("<script") && fileContent.Contains("/script>"));
        }
    }

You can register it during startup or with a composer.

This is an example of registering the class with a composer:

public class ServerSideValidationComposer : IComposer
    {
        public void Compose(IUmbracoBuilder builder)
        {
            builder.Services.AddSingleton<IFileStreamSecurityAnalyzer, SvgXssSecurityAnalyzer>();
        }
    }

Then you can upload a file with the following content to the backoffice and see that it is not persisted.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
   <script type="text/javascript">
      alert('xss');
   </script>
</svg>

The Rich Text Editor is sanitized on the frontend by default, however, you may want to do this serverside as well. The libraries that are out there tend to have strict dependencies. That is why we will leave it up to you how you want to sanitize the HTML.

Implementing your own IHtmlSanitizer

We have added an abstraction called IHtmlSanitizer, which by default does nothing. You can override it with your own implementation to handle sanitization as you see fit. This interface has a single method: string Sanitize(string html). The output of this method is what will be stored in the database when you save a Rich Text Editor.

To add your own sanitizer you must first create a class the implements the interface:

using Umbraco.Cms.Core.Security;

namespace MySite.HtmlSanitization;

public class MyHtmlSanitizer : IHtmlSanitizer
{
    public string Sanitize(string html)
    {
        // Sanitize the html parameter here
        return "<h1>Sanitized HTML</h1>";
    }
}

The Sanitize method in this implementation is where you can use a library. You could also use your own sanitizer implementation, to sanitize the Rich Text Editor input.

Now that you've added your own custom IHtmlSanitizer you must register it in the container to replace the existing NoOp sanitizer.

You can register it directly in the Program.cs or use a composer.

The extension method could look like the following:

using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Cms.Core.Security;
using Umbraco.Extensions;

namespace MySite.HtmlSanitization;

public static class BuilderExtensions
{
    public static IUmbracoBuilder AddHtmlSanitizer(this IUmbracoBuilder builder)
    {
        builder.Services.AddUnique<IHtmlSanitizer, MyHtmlSanitizer>();
        return builder;
    }
}

The extension can then be invoked in the CreateUmbracoBuilder() builder chain in the Program.cs file:

builder.CreateUmbracoBuilder()
    .AddBackOffice()
    .AddWebsite()
    .AddDeliveryApi()
    .AddComposers()
    .AddHtmlSanitizer() // Call you extension method here.
    .Build();

Another option is to create a composer for handling the extension method:

using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Cms.Core.Security;
using Umbraco.Extensions;

namespace MySite.HtmlSanitization;

public class SanitizerComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddUnique<IHtmlSanitizer, MyHtmlSanitizer>();
    }
}

With your custom sanitizer in place the Rich Text Editor will always contain the "Sanitized HTML" heading. This shows that everything is working as expected, and that whatever your sanitizer returns is what will be saved.

It's impossible to brute force the authentication on the login screen because after MaxFailedAccessAttemptsBeforeLockout the account of the user will be locked, and until that account is unlocked in the Users section, no attempt will succeed.

Password reset on login screen

When you submit the password reset form, an email is sent to the user with a link. This link contains a random token for this user that is valid for 24 hours.

The settings AllowPasswordReset is documented in the Umbraco Security Settings and e-mail configuration settings in Backoffice Login Password Reset Section

Password reset of a non-existing user

If the user that is specified in the form does not exist, no e-mail will be sent and there will be no response in the form that this user does not exist. This is done to prevent leaking which users have an account.

Password reset of a locked user

If a user is locked out, it is possible to do a password reset. After the e-mail with the password reset link is followed, the user will still be locked out unless the user has specified the new password, in which case the user will automatically be unlocked.

Reset admin user password

If you lost the admin user password and you need to reset it, check this article.

Two-factor authentication (2FA) for Umbraco members is activated by implementing an ITwoFactorProvider interface and registering the implementation. The implementation can use third-party packages to archive for example support for authentication apps like Microsoft- or Google Authentication App.

Two-factor authentication for Members

Since Umbraco does not control how the UI is for member login and profile edit. The UI for 2FA is shipped as part of the Partial View snippets. These can be used as a starting point, before styling the page as you would like.

Example implementation for Authenticator Apps for Members

In the following example, we will use the GoogleAuthenticator NuGet Package.

Despite the name, this package works for both Google and Microsoft authenticator apps. It can be used to generate the QR code needed to activate the app for the website.

using System;
using System.Threading.Tasks;
using Google.Authenticator;
using Umbraco.Cms.Core.Security;
using Umbraco.Cms.Core.Services;

namespace My.Website;

/// <summary>
/// Model with the required data to setup the authentication app.
/// </summary>
public class QrCodeSetupData
{
    /// <summary>
    /// The secret unique code for the user and this ITwoFactorProvider.
    /// </summary>
    public string Secret { get; init; }

    /// <summary>
    /// The SetupCode from the GoogleAuthenticator code.
    /// </summary>
    public SetupCode SetupCode { get; init; }
}

/// <summary>
/// App Authenticator implementation of the ITwoFactorProvider
/// </summary>
public class UmbracoAppAuthenticator : ITwoFactorProvider
{
    /// <summary>
    /// The unique name of the ITwoFactorProvider. This is saved in a constant for reusability.
    /// </summary>
    public const string Name = "UmbracoAppAuthenticator";

    private readonly IMemberService _memberService;

    /// <summary>
    /// Initializes a new instance of the <see cref="UmbracoAppAuthenticator"/> class.
    /// </summary>
    public UmbracoAppAuthenticator(IMemberService memberService)
    {
        _memberService = memberService;
    }

    /// <summary>
    /// The unique provider name of ITwoFactorProvider implementation.
    /// </summary>
    /// <remarks>
    /// This value will be saved in the database to connect the member with this  ITwoFactorProvider.
    /// </remarks>
    public string ProviderName => Name;

    /// <summary>
    /// Returns the required data to setup this specific ITwoFactorProvider implementation. In this case it will contain the url to the QR-Code and the secret.
    /// </summary>
    /// <param name="userOrMemberKey">The key of the user or member</param>
    /// <param name="secret">The secret that ensures only this user can connect to the authenticator app</param>
    /// <returns>The required data to setup the authenticator app</returns>
    public Task<object> GetSetupDataAsync(Guid userOrMemberKey, string secret)
    {
        var member = _memberService.GetByKey(userOrMemberKey);

        var twoFactorAuthenticator = new TwoFactorAuthenticator();
        SetupCode setupInfo = twoFactorAuthenticator.GenerateSetupCode("My application name", member.Username, secret, false);
        return Task.FromResult<object>(new QrCodeSetupData()
        {
            SetupCode = setupInfo,
            Secret = secret
        });
    }

    /// <summary>
    /// Validated the code and the secret of the user.
    /// </summary>
    public bool ValidateTwoFactorPIN(string secret, string code)
    {
        var twoFactorAuthenticator = new TwoFactorAuthenticator();
        return twoFactorAuthenticator.ValidateTwoFactorPIN(secret, code);
    }

    /// <summary>
    /// Validated the two factor setup
    /// </summary>
    /// <remarks>Called to confirm the setup of two factor on the user. In this case we confirm in the same way as we login by validating the PIN.</remarks>
    public bool ValidateTwoFactorSetup(string secret, string token) => ValidateTwoFactorPIN(secret, token);
}