Using federated authentication with Sitecore
Historically, Sitecore has used ASP.NET membership to validate and store user credentials. With ASP.NET 5, Microsoft started providing a different, more flexible validation mechanism called ASP.NET Identity.
ASP.NET Identity uses Owin middleware components to support external authentication providers. These external providers allow federated authentication within the Sitecore Experience Platform.
Sitecore:
- Uses Owin middleware to delegate authentication to third-party providers.
- Gets claims back from a third-party provider.
Federated authentication is not available by default. You must:
- Configure third-party providers.
- Map claims received from third-party providers to Sitecore user properties (user profile data) and roles.
- Rename the
Sitecore.Owin.Authentication.Enabler.config.example
file from the \App_Config\Include\Examples\ folder to theSitecore.Owin.Authentication.Enabler.config
file. - Set the authentication mode to
None
in theWeb.config <authentication mode="None" />
- Remove the FormsAuthentication module:
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
The configuration includes patching the configuration/sitecore/federatedAuthentication
config node as well as writing a custom processor for the owin.identityProviders
pipeline.
You can use Sitecore federated authentication with the providers that Owin.Authentication supports. Most of the examples in our documentation assume that you use Azure AD, Microsoft’s multi-tenant, cloud-based directory and identity management service.
Owin.Authentication supports a large array of other providers, including Facebook, Google, and Twitter.
Federated authentication works in a scaled environment.
Cookies and federated authentication
If you do not use Sitecore.Owin.Authentication, the default authentication cookie name is .ASPXAUTH
. You can change this in the Web.config
file:
<authentication mode="Forms">
<forms name=".ASPXAUTH" cookieless="UseCookies" />
</authentication>
If you use Sitecore.Owin.Authentication, however, the .ASPXAUTH
cookie is not used. Therefore, you must not use this cookie directly from code.
Because Sitecore.Owin.Authentication overrides the BaseAuthenticationManager
class and does not use the FormsAuthenticationProvider
class underneath, it is not a problem that the .ASPXAUTH
authentication cookie is missing for any code that uses the AuthenticationManager
class.
AspNet.Cookies
– authentication cookie for logged in usersAspNet.Cookies.Preview
– authentication cookie for preview mode users
These cookies let users log in and log out as different users in the Experience Editor Preview mode, and view Sitecore pages as different users with different access rights.
Sitecore constructs names are constructed like this:
".Asp." + AuthenticationType + AuthenticationSource.
- The
AuthenticationType
isCookies
by default and you can change it in theOwin.Authentication.DefaultAuthenticationType
setting. - The
AuthenticationSource
isDefault
by default. It is not included in the cookie name when it isDefault
. TheAuthenticationSource
allows you to have multiple authentication cookies for the same site.
- The
You configure Owin cookie authentication middleware in the owin.initialize
pipeline.
Virtual and persistent users
Federated authentication supports two types of users:
- Persistent users – Sitecore stores information about persistent users (login name, email address, and so on) in the database, and uses the Membership provider by default
- Virtual users – information about these users is stored in the session and disappears after the session is over.
There are a number of limitations when Sitecore creates persistent users to represent external users. Sitecore does not support the following features for such users:
- Reading and deleting roles of external users in the User Manager because these roles are not stored in Sitecore.
- Because of this, using the Access Viewer.
- Changing a user password. You have to change passwords
it in the corresponding identity provider.