Authentication Options with the Sitecore ASP.NET CMS

The barebones custom MembershipProvider thread on the Sitecore Developer Network (SDN) forums prompted me to write this blog post that describes several potential mechanisms for authenticating users of the various sites with the Sitecore ASP.NET CMS. For more information about authentication with Sitecore, see the Security API Cookbook on SDN.

Sitecore uses ASP.NET security providers that abstract the details of authentication (membership), authorization, and roles (*not* called membership). This blog post describes only membership (authentication) providers.

You can use at least the following techniques to authenticate users:

  • Default: The default Sitecore membership provider uses tables in the Core database based on the standard ASP.NET membership schema. You can use the default membership provider in nonstandard ways, such as using a dedicated security database, spoofing an existing user or creating a user automatically after authenticating a user against an external system. For more information about the default membership provider, see the Security Reference on SDN.
  • Active Directory Providers: You can use the Sitecore Active Directory module to authenticate users with Microsoft Active Directory. Technically, the Active Directory module consists of ASP.NET membership, role and profile providers that authenticate and otherwise operate against Active Directory.
  • Microsoft CRM Provider: You can use the Sitecore CRM Security Provider to authenticate users with Microsoft Dynamics CRM. If you've ever logged in to SDN, you've used this provider.
  • Custom Provider: You can implement a custom ASP.NET membership provider to authenticate users against an existing system. Technically, the Active Directory and CRM modules consist of pre-built ASP.NET membership, role and profile providers that authenticate and otherwise operate against Microsoft Active Directory and CRM instances. For more information about implementing membership providers, see Membership Providers on SDN. Providers provide complete authentication integration.
  • Federated: Federated authentication and identity management is beyond the scope of this blog post.
  • Virtual Users: After you authenticate a user against an external system, you can invoke APIs to create a virtual user in Sitecore. Any information about virtual users that you don't store in the external system is transitory. Virtual users provide lightweight authentication integration. For information about APIs for working with virtual users, see the Virtual Users page on SDN.

Note that using techniques such as switching providers as described in Low-level Sitecore Security and Custom Providers on SDN, and other techniques such as multiple login pages with different code-behind, you can use different approaches for different systems and security domains, such as using Active Directory for CMS users and the default provider for users on the published web site. Regardless of which approach you use, the security model provides the user, role, profile, domain and related abstractions.

I've probably forgotten at least one authentication option. If you know of additional authentication options, or of reasons to choose one option over another, please comment on this blog post.

  • How does creating users to login to a website (not the CMS) effect licensing, presumably not at all?

  • @Tom: I checked with a senior sales person within Sitecore and you are correct: Sitecore has no concept of licensing limits (concurrent, total, or otherwise) for visitors to the published sites; the only limits apply to users of the CMS.

  • Hi Tom, Did you get any feedback on when to use one option over another? Or can you direct my to a source of information this - especially with regards to Active Directory?

  • Sten,   This depends what you want to do. I wanted to hold my users in a separate user repository to Sitecore's own (membership database), and to do that I use Switching Membership Provider, this basically bridges together two authentication mechanisms that can run off of ASP.NET membership providers, so AD is supported here.   John may be able to shed more light on anything more specific.   Cheers Tom

  • Hi John,  Developers also have the option of subclassing  or decorating existing ASP.NET MembershipProviders.    I showed an example of how to decorate the "out of the box" SqlMembershipProvider in a custom MembershipProvider to prevent users from using common dictionary words  -- names of fruit in my example -- in their Sitecore passwords:  Kind regards,  Mike

  • John,  Have you written a post outlining the Federated option in more detail??  cheers Johnny

  • I have not, but have you seen this:  I believe there are some other public resources about federated authentication, such as Sitecore Social Connected, but this is not my area of expertise. Connected 13.aspx

  • Hi, Is it possible to use SAML 2.0 to allow SSO (Single Sign on)?  Regards, Ivan

  • Hi, I too am interested in how SAML 2.0 works with Sitecore, can you give any details or point us to some documentation on its implementation?

  • @Ivan and @John: I am not familiar with SAML 2.0. What APIs are available for .NET? If there is no membership provider, and implementing such a provider does not seem like a good idea, I wonder if you could consider virtual users.  Would you use SAML only for authentication, or for authornization (role membership) and/or user profile information as well?

  • Hi John,  Based on your suggestion, I authenticate the user base on   third party Active Directory Federation Service, then  create  virtual user and assign roles to it.  The authentication works.  However,  I couldn't publish with the virtual user because the "PublishHelper.cs" by default use  "SqlAuthorizationProvider .cs".  Since it is virtual user, it always return "no access".   In this case, should I implement a custom AuthorizationProvider ?  Any suggestion?

  • Hi John,  One more question about the ClientContext.  After sign in with virtual user, I managed to store the meta data to ClientContext.   Code Snip as :  ClientContext.SetValue("SC_USR_" + user.Name, runtimeSettings.Serialize());   My understanding is that the value will be saved in client data cache for late use.  However, I couldn't retrieve  it in  My customed PublishItemProcessor.     public class MyTestCheckSecurity : PublishItemProcessor     {          public override void Process(PublishItemContext context)         {           string text2 = ClientContext.GetValue("SC_USR_" + context.User.Name) as string;          }       }

  • Hi John  Not sure if this would help you become more familiar with SAML 2.0 but its the best I cna offer at the moment.  We are using sitecore to build a new version of an old web page.  Since we are using a specific vendor for SSO it would be better to have sitecore SAML 2.0 compliant to work with that vendor.  I know we can use the MS Fed methods but our preference is to use SAML 2.0 where ever possible.  As I find out more I will let you know  thanks  John