As you probably know in Sharepoint the single web application can be extended on several authentications zones. Administrator can specify authentication type for each zone: Windows (NTLM) or FBA (via Central Administration > Application Management > Authentication providers). So internal users will be able to login the system using their windows accounts while external users, which access system by Internet – will use FBA. When NTLM authentication is used there is one convenient group “NT Authority/Authenticated Users” which represents all Windows-authenticated users who have access to your network (see this blog post for details). Why it is convenient? Because with this group administrators are able to manage permissions for all authenticated users at once.
But when you use FBA there is no such suitable group which all authenticated FBA users belong to. As you know FBA is implemented by membership and role providers (inheritors of standard MembershipProvider and RoleProvider from System.Web.dll). Actual implementation of these providers depends on physical storage of users accounts (most common are Sql database and Active Directory). If standard Sql database aspnet_db is used as backend storage for FBA then the following standard providers are available:
If you use Active Directory you can use the following providers:
As I said above whatever provider you use, there is no analogue of “NT Authority/Authenticated Users” group for FBA. In order to implement this functionality several ways may be used. But all of them are variations of one single idea: there is one special FBA group AllUsers – and administrators will use this group in order to manage permissions in Sharepoint (i.e. they will asign permissions for this group on various securable objects in MOSS). But how users will become members of this group? You can consider several ways:
- If you have full control on user creation (e.g. there is only one single self-registration page in whole system) then you can customize process of registration by adding custom code which will add newly created user to AllUsers group;
- If you have no full control on user creation process (i.e. if users are created automatically using BizTalk integration with external CRM system), you may implement Sharepoint job which will run by the scheduler and add all users to special FBA group AllUsers (which should be created before any actions with users). Advantage of this approach is that you will still use standard providers and real FBA group AllUsers, i.e. there will be no custom solutions for it. But from another point of view FBA users will not be member of AllUsers group immediately after their creation. There should be some time until Sharepoint job will run and adds new user accounts to AllUsers group.
- If you have no full control on user creation process but previous solution with asynchronous Sharepoint job is not suitable for you, then you can implement custom role provider which will “emulate” this special FBA group AllUsers.
In this post I will describe 3rd method and show how to implement custom role provider in case of Sql database user storage (i.e. if standard aspnet_db is used). But of course it will not limit you from creation of custom providers for Active Directory as ideas described here are general for all types of storages.
I.e. idea is the following: as we use standard Sql database aspnet_db we can still use standard SqlRoleProvider. But in order to add our “virtual” FBA group AllUsers we need to inherit our custom provider from this class and add necessary logic here. Lets look at public interface of SqlRoleProvider class and see what methods we should override in order to add our virtual FBA group. Here they are:
So in order implemented mentioned idea we need to override these 6 methods consistently. By consistently I mean that they should not contradict with each other. E.g. if method GetRolesForUser() returns “AllUsers” group for user “john” it means that method GetUsersInRole() for role “AllUsers” group should return “john” as well as other users. Also method IsUserInRole() for “AllUsers” group for user “john” should return true, etc. Also we want to keep any existing logic of standard SqlRoleProvider class untouched in order to avoid side effects caused by custom role provider. Custom role provider should be implemented as much safely as possible.
After formalizing the requirements we can implement custom role provider based on SqlRoleProvider. Here is the code:
Here I used convenient extension method IsNullOrEmpty() for IEnumerable<T> decribed in this post of Phil Haack:
Lets consider for example method IsUserInRole(). At first it checks on null or empty userName or roleName and if one of these conditions is true – call base implementation as we don’t want to handle special cases by ourselves. After this we check whether or not roleName is our special group “AllUsers” (method isSpecialGroup()) and if yes – we just check whether user exists or not. We don’t check user’s membership in any group because it is not important for us in case of “AllUsers” group. All we need to know is whether specified user exists or not. If user exists we return true – it means that user belongs to AllUsers group.
The rest of methods are implemented by the same schema – if “AllUsers” group is specified in params we just introduce special case for it. In all other cases base implementation is called. Doing this we ensure that existing functionality of SqlRoleProvider will be preserved.
After this the only thing which should be done is to install assembly with custom provider into GAC and replace standard SqlRoleProvider in web.config of your web application:
As I said above the same idea can be used for others role providers as well. Using described approach you will be able to “virtualize” AllUsers FBA group without having the real AllUsers group in your backend FBA storage.