WSS and Custom Authorization Provider

As is well known by now, WSS 3.0 (and consequently MOSS) supports the ability to plug-in a custom role provider. So instead of being limited to the default AD based role provider, a custom store such as SQL database, can be used as the authorization store. As you can imagine, this gives you a lot flexibility in terms of storing and managing users.

Let us examine custom role provider in detail. But before we proceed, let us get a few core definitions out of the way. WSS defines the following core set of security related objects:

o SPUser and SPGroup – SPUser represents a user, while SPGroup as the name suggests, represents a collection of users. WSS allows you to create custom groups.

o SPBasePermission, SPRoleDefinition and SPRoleAssignment- SPBasePermission is right to perform a certain action within WSS. For example the right to insert list items. SPRoleDefinition is a collection of rights. For example, Contributor, Designer are built-in roles. Finally, SPRoleAssignment defines the assignment of roles for SPUser or SPGroup

Irrespective of whether you use a custom authorization provider or not, WSS creates instances of above mentioned set of objects to manage security within WSS. For example, SPRoleDefinition object that we discussed above, relies on SPUser and SPGroup for role-to-permission mapping.

So how does custom provider help? Using a custom provider you can create roles and include them as part of SPGroup (much like you would include instances of SPUser). This is an important benefit as you grant access based on custom authorization rules, stored outside of WSS.

There is another important benefit enabled by custom role providers – Ability to manage authorization rules across site collections (SPSiteCollection). A SPSiteCollection is a security boundary within WSS. This means that SPUsers and SPGroups defined within one SPSiteCollection are not available to other SPSiteCollection instances.

A custom role, however, can span multiples site collections since the authorization provider is defined at the Web Application level (SPWebApplication). This way you can manage authorization across sites from one central administrative interface. On the contrary, if you only had to rely on SPGroups for authorization, you would have to create a separate SPGroup for each SPSiteCollection and develop a scheme to keep them synchronized.

I should add that AD groups can be used to achieve the same behavior as described above (I.e. ability to span SPSiteCollections). However, the way AD is administered in most organizations, WSS Site owners do not have the permissions to create and modify AD groups.