Wednesday, November 30, 2011

Being Ignored By the SQL Membership Provider

SQL Membership Provider in SharePoint 2010

Those of you who have worked on SharePoint 2010 sites that use Forms Based Authentication (under the umbrella of Claims Based Authentication), won’t act surprised when I start talking about the SQL Membership Provider. It’s one of the most common providers that gets used in SharePoint 2010 FBA sites. The fact that it’s a free, very flexible, and pretty straight forward way to set up FBA in SP 2010 have helped spur its popularity.
Those who have also worked with the SQL Membership Provider in environments where claims based authentication wasn’t in play, may very well have noticed some changes in its behavior. While the code is of course the same, the additional complexity of a claims environment, means that some properties may not behave as they normally would.

The Computer Isn’t Listening to Me

On two separate occasions now we’ve had developers set properties on the SQL Membership Provider in the web.config expecting it to change the behavior of their SP 2010 site. In both these cases a lack of understanding in how claims authentication works has left them scratching their heads when the properties didn’t take effect.
An example of this might be:
  • Developer wants to change one of the authentication options of the membership provider (say increase the MaxInvalidPasswordAttempts property), and does so in the web.config of the chosen web application.
  • After the change to the provider settings, the developer notices that the web application behaves no differently than before.
  • After a series of cuss words and IIS resets, developer starts aimlessly searching the internet (or an empty bottle) for the answer.
It’s important to remember that once claims based authentication is introduced, the web application doesn’t perform any of the authentication anymore. Even though those settings for the provider in the web.config speak to authentication behavior, in Sharepoint 2010 claims auth scenarios the actual authentication is most often performed by the SharePoint Secure Token Service.
Those web.config settings (in the web application) that don’t speak to authentication are still fair game and will behave as expected, but the properties that change auth behavior like MaxInvalidPasswordAttempts or PasswordAttemptWindow won’t have any effect (unless their made in the Secure Token Service web.config).
To be clear, you need to make those changes to the web.config of the STS, normally hosed at: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken\web.config.
In most scenarios, the authentication exchange looks like the picture below (with steps 3-8 being performed by the STS).
Claims Authentication Steps for Browser and Secure Token Service
Once the relationship between the user, the STS, and the web application become clear the reasoning behind this behavior starts to make a lot more sense.
Since knowing is half the battle, it’s probably worth keeping an eye on claims based authentication technologies and how they behave. With how many systems are now using shared/claims auth both in and outside the enterprise, these are troubleshoots that are going to become increasingly common in future years.
My Best,

1 comment:

digital id said...

Very helpful article ! I was always curious about all these complex algorithms that are being used in these ssl encryptions.