Sitecore uses the https://msdn.microsoft.com/en-us/library/ms731049(v=vs.110).aspx framework for managing its users, and also provides this as a means for you to manage your own users of your website in the extranet domain (or other domains that you have implemented).

In certain cases, you may want to implement your own custom backing store for users, rather than the default SQL Server provider. Fortunately, Sitecore includes a mechanism so that it can support multiple providers under one website, this is through the SwitchingProviders within the Sitecore.Security namespace.

There are already a number of useful links covering implementing your own custom membership provider using the Switcher:

This is just a short blog post to highlight a couple of a small gotcha that you may encounter, due to some inconsistencies in Sitecore’s implementation of the Switching providers.

The issue

The first link in the above list is the official Sitecore documentation for implementing new providers. In 3.1.1 Configuring Switching Providers, the following attributes for defining providers via a SwitchingProvider are defined:

  • ProviderName
  • StoreFullNames
  • Wildcard
  • Domains

Whilst these are the properties for the SwitchingMembershipProvider, the remaining providers have a couple of additional undocumented options, that have a large affect on how they operate:

SwitchingRoleProvider

The Role Provider adds an additional 2 undocumented properties:

ignoredUserDomains - If this is specified, then the provider won’t apply to the domains listed. Multiple domains should be comma-separated.
allowedUserDomains - If this is specified, then the provider will only apply to the domains listed. Multiple domains should be comma-separated.

As you can see, the way these two operate are at odds with each other (one is a blacklist, the other a whitelist). The provider only expects there to be one provided,; if you provide both, it will throw an exception.

Note that for this provider, the domain property is completely ignored. This can cause some real confusion if you have implemented a new provider and you are wondering why it is getting called for other domains, even though you’ve specified a domain there.

SwitchingProfileProvider

The Profile Provider adds just the one additional property:

ignoredDomains - This works exactly the same as ignoredUserDomains for the Role Provider.

And that’s it. No option for a whitelist only, and again, the domain property is ignored.

It’s not clear why the Role + Profile providers don’t just provide the same properties as each other, nor why these aren’t available to the Membership Provider. This might just be a small gotcha, but it’s worth taking note of this little eccentricity of the code.