Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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.
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
How to take advantage of the built-in rate limiting middleware of ASP.NET Core in Umbraco.
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.
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
You can configure rate limiting in Umbraco by composition. To use the middleware, you need to register the rate limiting services first:
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:
With the set-up in place, let's take a look at some limiter options.
Inside AddRateLimiter()
we can use the GlobalLimiter
option to set a global rate limiter for all requests:
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.
If you want to be more granular, you can configure different rate limits for different endpoints in AddRateLimiter()
as well:
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
:
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.
This section includes information on Umbraco security, its various security options and configuring how authentication & authorization works in Umbraco
In this article, you will find everything you need regarding security within Umbraco.
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.
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.
Learn which password settings that can be configured in Umbraco.
Learn about how to harden the security on your Umbraco website to secure it even further.
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.
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.
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.
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
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.
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
.
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.
How to configure Umbraco to run on a FIPS compliant server.
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.
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:
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:
Register the MyPasswordChecker
in your Program.cs
file:
If the username entered in the login screen does not exist in Umbraco, then MyPasswordChecker()
does not run. Instead, Umbraco will immediately fall back to its internal checks, which is the default Umbraco behavior.
There is one default admin user in any Umbraco installation. This is the first user of the system.
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:
Note that configuration can be read from many sources
Remember to check this connection string is not provided through environment variables or other configuration sources.
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.
Make sure you protect a production websites from being highjacked as anyone will be able to reset the password during the last step. This does also work if your site is in an upgrading state.
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.
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 and e-mail configuration settings in
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.
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.
If you lost the admin user password and you need to reset it, .
Umbraco supports supports external login providers (OAuth) for performing authentication of your users and members.
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.
Unlike previous major releases of Umbraco the use of the Identity Extensions package is no longer required.
Install an appropriate Nuget package for the provider you wish to use. Some popular ones found in Nuget include:
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:
To register these two classes in Umbraco CMS you need to add them to the Program.cs
file.
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 creating of user accounts on the external login provider and then automatically give them access to Umbraco. This is called auto-Linking.
When have auto-linking 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.
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.
This is a simplistic example of brevity including no null checks, etc.
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.
Be aware that the local Umbraco user must already exist and be linked to the external login provider before data can be stored here. In cases where auto-linking occurs and the user isn't yet created, you need to store the data in memory first during auto-linking. Then you can persist the data to the service once the user is linked and created.
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.
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.
The following section presents a series of generic examples.
"Provider" is used to replace place of the names of actual external login providers. When you implement your own custom authentication, you will need to use the correct method names for the chosen provider.
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.
In earlier versions of Umbraco up to version 12, the options included only a "ButtonStyle" property to style the button. In version 13+ the default button is now rendered using the Umbraco UI library. This means that the "ButtonStyle" property has been deprecated and should not be used. You can override the default styling of the button by using the "ButtonColor" and "ButtonLook" properties. We recommend leaving these properties empty to use the default styling. The default styling will give your users an optimal login experience.
Icons
If you want to use a custom icon for the login button, you need to add the icon to the Umbraco backoffice. You can do this by adding the icon to the ~/App_Plugins/MyPlugin/BackOffice/Icons
folder. The icon should be a SVG file. The icon should be named the same as the icon name you specify in the options.Icon
property.
Additionally, more advanced custom properties can be added to the BackOfficeExternalLoginProviderOptions
.
In earlier versions of Umbraco up to version 12, this property had to define an AngularJS HTML view. This is no longer the case. You can now define a JavaScript module to render a Custom Element instead of the default external login button.
It is still supported to load an HTML file as a view. However, Umbraco no longer supports AngularJS and the HTML file will be loaded into the DOM as-is. You will have to implement all the logic yourself.
You want to display something different where external login providers are listed: in the login screen vs the backoffice panel vs on the logged-out screen. This same view will render in all of these cases but you can use the current route parameters to customize what is shown.
You want to change how the button interacts with the external login provider. For example, instead of having the site redirect on button-click, you want to open a popup window to load the external login provider.
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 required logic.
The module should define a Custom Element and export it as default. The Custom Element can optionally declare a number of properties to be passed to it. These properties are:
providerName
: The name of the provider. This is the same name as the provider's scheme name.
displayName
: The display name of the provider. This is the same display name as the provider's display name.
externalLoginUrl
: The URL to redirect to when the button is clicked.
userViewState
: The current view state of the user. This can be one of the following values:
loggingIn
: The user is on the login screen.
loggedIn
: The user is on the backoffice panel.
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:
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.
We have to define a template first and then the custom element itself. The template is a small HTML form with a button. The button will submit the form to the externalLoginUrl
property. The custom element will then render the template and attach it to the shadow DOM and wire up the externalLoginUrl
property in the connectedCallback
method.
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.
The BackOfficeUserManager is the ASP.NET Core Identity UserManager implementation in Umbraco. It exposes APIs for working with Umbraco User's via the ASP.NET Core Identity including password handling.
The BackOfficeUserManager
is the ASP.NET Core Identity implementation in Umbraco. It exposes APIs for working with Umbraco Users via the ASP.NET Core Identity including password handling.
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).
You can replace the BackOfficeUserManager in the startup class by using the SetBackOfficeUserManager
extension on the IUmbracoBuilder
.
You can then implement your custom BackOfficeUserManager
, like this. Note the constructor minimum needs to inject what is required for the base BackOfficeUserManager
class:
SendEmailNotification
UserLogoutSuccessNotification
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.
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.
Name | Purpose | Expiration |
---|
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();
For information on the rest of the cookies, see the file on Github.
Here you find some tips and trick for hardening the security of your Umbraco installation.
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
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.
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.
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.
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".
Lock down the Umbraco folder by putting this rule into your IISRewrite-rules
If your server is behind a load balancer, you should use {HTTP_X_FORWARDED_FOR}
instead of {REMOTE_ADDR}
as the input for the rule.
If you now go to /umbraco/
from a different IP-address the login screen will not be rendered.
Custom-named configuration to add additional configuration for handling different options related to the authentication.
A static extention class to extend on the default authentication implementation in Umbraco CMS for either Users or Members.
It is also possible to register the configuration class directly into the extension class. See examples of how this is done in the .
Do not flow large amounts of data into the backoffice identity. This information is stored in the backoffice authentication cookie and cookie limits will apply. Data like Json Web Tokens (JWT) needs to be somewhere to be looked up and not stored within the backoffice identity itself.
You can use the to see available icons.
The CustomBackofficeView
allows for specifying a JavaScript module to render a instead default external login button. Use this in case you want to change the UI or one of the following:
You have access to the in the custom element. You can use the components directly in your custom element.
It is also possible to use a library like to render the custom element. The following example shows how to use Lit to render the custom element. The custom element will render a form with a button. The button will submit the form to the externalLoginUrl
property. We do not have to perform any logic in the connectedCallback
method because Lit will automatically update the action
attribute on the form when the externalLoginUrl
property changes. We can even include other properties like displayName
and providerName
in the template without having to react to changes in those properties. Styling is also handled by Lit in the static styles
property.
We are using Lit version 3 in this example imported directly from a JavaScript delivery network to keep the example slim. You can also use a bundler like to bundle the Lit library with your custom element.
For a more in-depth article on how to set up OAuth providers in .NET refer to the .
There are you can handle on the BackOfficeUserManager
. Internally these are mainly used for auditing but there are some that allow you to customize some workflows:
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 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.)
This is specifically used if you have an 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.
UMB_PREVIEW | Allows a previewed page to act as a published page only on the browser which has initialized previewing. | Session |
UMB-WEBSITE-PREVIEW-ACCEPT | Client-side cookie that determines whether the user has accepted to be in Preview Mode when visiting the website. | Session |
umb_installId | Used to store the Umbraco software installer id. | Session |
UMB_UPDCHK | Enables your system to check for the Umbraco software updates. | Session |
UMB-XSRF-V | Used to store the backoffice antiforgery token validation value. | Session |
UMB-XSRF-TOKEN | Set for angular to pass in to the header value for "X-UMB-XSRF-TOKEN" | Session |
TwoFactorRememberBrowser | Default authentication type used for storing that 2FA is not needed on next login | Session |
UMB_SESSION | Preserves the visitor's session state across page requests. | Session |
This tutorial walks through configuring Umbraco and Lucene to be FIPS compliant and serve up websites on a server with FIPS enabled.
FIPS should only be added for compliance. It is not a recommended approach for added security. For more information read Why Microsoft is not recommending "FIPS Mode" anymore.
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.
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
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.
Since Umbraco 9, the dependency to Lucene.NET is updated to version 4+. Thereby are both Umbraco and all key dependencies FIPS compliant.
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.
This article covers the recommended way of working with HTTPS and Umbraco CMS.
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.
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.
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 is redirected to https
All self delivered Umbraco requests (those are scheduled publishing, keep alive, etc...) 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
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:
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.
The rule includes an ignore for localhost
. If you run your local environment on a different URL than localhost
you can add additional ignore rules. Additionally, if you have a staging environment that doesn't run on HTTPS, you can add that to the ignore rules too.
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.
This section describes how to sanitize the Rich Text Editor serverside
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.
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:
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.
Learn more about registering dependencies and when to use which method in the Dependency Injection article.
The extension method could look like the following:
The extension can then be invoked in the CreateUmbracoBuilder()
builder chain in the Program.cs
file:
Or you can use a Composer:
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.
This section describes how you can implement File Validation
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.
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
The following class shows how one could potentially guard against Cross-site scripting(XSS) vulnerabilities in an svg file.
You can register it during startup or with a composer.
This is an example of registering the class with a composer:
Then you can upload a file with the following content to the backoffice and see that it is not persisted.
Umbraco users and members support a two-factor authentication (2FA) abstraction for implementing a 2FA provider of your choice.
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.
If you are using Umbraco Cloud, you can enable multi-factor authentication in Umbraco ID. For more information, see the Multi-Factor Authentication article.
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 snippets for macros. These can be used as a starting point, before styling the page as you would like.
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.
First, we create a model with the information required to set up the 2FA provider. Then we implement the ITwoFactorProvider
with the use of the TwoFactorAuthenticator
from the GoogleAuthenticator NuGet package.
Now we need to register the UmbracoAppAuthenticator
implementation. This can be done on the IUmbracoBuilder
in your startup or a composer.
At this point, the 2FA is active, but no members have set up 2FA yet. The setup of 2FA depends on the type. In the case of App Authenticator, we will add the following to our view showing the edit profile of the member.
In this razor-code sample, we get the current member's unique key and list all registered ITwoFactorProvider
implementations.
If the setupData
is null
for the specified providerName
it means the provider is already set up. In this case, we show a disable button. Otherwise, we check the type and show the UI for how to set up the App Authenticator. We will show the QR Code and an input field to validate the code from the App Authenticator.
The last part required is to use the Login
Partial Macro snippet.
When a 2FA login is requested for a member, the MemberTwoFactorRequestedNotification
is published. This notification can also be used to send the member a one-time password via e-mail or phone. Even though these 2FA types are not considered secure as App Authentication, it is still a massive improvement compared to no 2FA.
Umbraco controls how the UI is for user login and user edits, but will still need a view for configuring each 2FA provider.
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.
First, we create a model with the information required to set up the 2FA provider. Then we implement the ITwoFactorProvider
with the use of the TwoFactorAuthenticator
from the GoogleAuthenticator NuGet package.
Now we need to register the UmbracoUserAppAuthenticator
implementation and the view to show to set up this provider. This can be done on the IUmbracoBuilder
in your startup or a composer.
Now we need to create the view we configured, in the path we choose.
As this view uses an angular controller, we need to create that class and configure it in the package.manifest
.
In package.manifest
, we point to the path of the angular controller that we are creating in the next step.
And we create the controller in that location:
At this point, the 2FA is active, but no users have set up 2FA yet.
Each user can now enable the configured 2fa providers on their user. This can be done from the user panel by clicking the user avatar.
When clicking the Configure Two-Factor
button, a new panel is shown, listing all enabled two-factor providers.
When clicking Enable
on one of these, the configured view for the specific provider will be shown
When the authenticator is enabled correctly, a disable button is shown instead.
To disable the two-factor authentication on your user, it is required to enter the verification code. Otherwise, admins are allowed to disable providers on other users.
If the code is correct, the provider is disabled.
When a 2FA login is requested for a user, the UserTwoFactorRequestedNotification
is published. This notification can also be used to send the user a one-time password via e-mail or phone. Even though these 2FA types are not considered secure as App Authentication, it is still a massive improvement compared to no 2FA.
When a user with 2FA enabled logs in, they will be presented with a screen to enter the verification code:
While the 2FA is enabled, the user will be presented with this screen after entering the username and password.
If the code is correct, the user will be logged in. If the code is incorrect, the user will be presented with an error message.
This screen is set up to work well with 2FA providers that require a one-time code to be entered. The code field follows best practices for accessibility in terms of labeling and autocompletion.
A user can have more than one 2FA provider activated simultaneously. In this case, the user will be presented with a dropdown to choose which provider to use before entering a code.
The 2FA login screen can be customized. This should be done if you have a 2FA provider that does not require a one-time code to be entered.
You should only customize the 2FA login screen in certain cases, for example:
If you have a provider that requires a non-numeric field or additional info.
If you have a provider that requires the user to scan a QR code, you should additionally show the QR code.
If you need to authenticate the user in a different way than the default AuthenticationController in Umbraco.
You need to create a JavaScript module that exports a default custom element to be used in the login screen. This module should be placed in the App_Plugins
folder. The module should be registered using a composer.
In earlier versions of Umbraco up to version 12, you had to define an AngularJS HTML view. This is no longer the case. You can now define a JavaScript module to render a Custom Element instead of the default two-factor login screen.
It is still supported to load an HTML file as a view. However, Umbraco no longer supports AngularJS and the HTML file will be loaded into the DOM as-is. You will have to implement all the logic yourself.
You can use the following code as a starting point. This will give you a view looking like this, where the user can enter a code and click a button to verify the code. This is similar to the built-in view in Umbraco. In a real world scenario, you would probably want to authenticate the user in a different way.
The following code is an example of a custom 2FA login screen using Lit. This is the recommended way of creating a custom 2FA login screen. Lit is a light-weight library that augments the Custom Elements API to provide a declarative, performant, and interoperable way to create web components.
The element registers two properties: providers and returnPath. These properties are used to render the view. The providers property is an array of strings, where each string is the name of a 2FA provider. The returnPath is the path to redirect to after a successful login. Both supplied by the login screen automatically.
We need to register the custom view using a composer. This can be done on the IUmbracoBuilder
in your startup or a composer. In this case, we will add a composer to your project. This composer will overwrite the IBackOfficeTwoFactorOptions
to use the custom view.
Marking fields and properties on member data as sensitive will hide the data in those fields for backoffice users that are not privy to the data.
In this article, you will get an overview of how you can grant and/or deny your users access to sensitive data as well as how to mark data as sensitive.
Every new Umbraco installation ships with a default set of User Groups. One of them is the Sensitive data User Group. To give users in the backoffice access to view and work with sensitive data, they need to be part of the Sensitive Data User Group.
Any users who are not part of the Sensitive Data User Group, will not be able to see the data in the properties that are marked as sensitive. Instead, they will see a generic message: "This value is hidden. If you need access to view this value please contact your website administrator."
While not part of the Sensitive Data User Group it is also not possible to export members or member data.
Follow these steps in order to grant a user access to sensitive data:
Navigate to the Users section in the Umbraco backoffice.
Ensure that Users are selected from the Users tree.
Select the Groups menu in the top-right corner.
Choose the Sensitive data group.
Click Add in the Users box on the right.
Select the users you want to give access to the sensitive data.
Click Submit.
Save the User Group.
The users you have added to the Sensitive Data User Group will now be able to:
See member data that has been marked as sensitive,
Mark data and properties on Member Types as sensitive, and
Export members and member data.
Once your user is added to the Sensitive Data User Group, you have access to add and configure member properties containing sensitive data.
Follow the steps below to mark data as sensitive.
Navigate to the Settings section in the Umbraco backoffice.
Open the Member Types in the Settings tree.
Select the Member Type you wish to edit.
Add a property or configure an existing property.
Locate the Is sensitive data option at the bottom of the Property settings dialog.
Click to enable.
Click Submit to update the property configuration.
Click Save to save the changes on the Member Type.
When the Is sensitive data option is enabled, the value and data in the property will only be visible to the users with access to sensitive data.