A while back, I was working on a unified security model for a framework when I discovered this issue.
The gist of this unified model is the passing of our dear interface friend,
System.Security.Principal.IPrincipal from the client to a component running on a remote server.
As I was testing this security model, I created a simple ASP.NET client application that used the new Role and Membership features. I made a call to the component passing the Page.User property to check the serialization of the principal object that ASP.NET assigned to the property. The type of the Page.User object when using the new role management services is that of System.Web.Security.RolePrincipal.
The interesting thing I found out about the RolePrincipal class is how it behaves in the case you specify roles in the <authorization /> section of web.config. If you specify something like this,
<authorization>
<deny users="?" />
<allow roles="Administrators" />
</authorization>
Serialization of RolePrincipal worked with no problems. However, when you switch the settings to be,
<authorization>
<deny users="?" />
</authorization>
You receive the following error: The Role Manager feature has not been enabled. The reason you get this error is because internally, the IsRoleListCached property of RolePrincipal is set to false when you don't specify a list of roles for access. Since this property is false, the RolePrincipal will create an instance of your specified RoleProvider and try to call it (thus the failure). If you specify a role (or roles), the ASP.NET runtime will initialize this property to true and prevent the calling of your RoleProvider.
More to come on this...