The built-in RoleProvider has, IMO, a major flaw in its design. Both the RoleProvider and the MembershipProvide allow for an "applicationName" attribute to be set. However, you quickly find out that when you have a RoleProvider configured, that the Membership static methods simply ignore the applicationName on the Membership provider and instead uses the applicationName from the RoleProvider. The assumption being that the source of the Roles is the same as the source for the Users. That's fine and dany when this assumption is true. However, what happens when you are say building a suite of applications that should each have their own roles, but you want to use a centralized list of users? An example, might be a suite of applications installed at a customer where the customer desires to use the ActiveDirectoryMembershipProvider.
As it stands now, the only way to accomplish this feat is to use AzMan for all of your applications. Unfortunately, AzMan is a bear to use and does not provide the ability to create a web interface whereby you can call AddUserInRoles. What the user really wants in this situation is the user search functionality so that they can search for users on their Active Directory domain. Of course you can do this via the AzMan mmc, but if you ever have to hand off your application for someone else to install, you quickly realize that you have to write a bazillion instructions for configuring AzMan which is a problematic pain in the neck (see Commerce Server 2007).
What would be peachy would be a way of using the SqlRoleProvider with ActiveDirectory. That is what I have worked together and I'll post the code in an ensuing post. However, in general the idea is to have a SqlRoleProvider that you use for all authorizations but allow for a different MembershipProvider for authentication and then store a flag which determines whether authenticated users should automatically be added to a given role in the SqlRoleProvider store. In effect, you are always using the SqlRoleProvider but ensuring that authentication is always done via the cutomer's preferred MembershipProvider.
.NET Development