There are unnecessary dependencies between verification and authorization of the username type information of WCF Security

Recently, I am developing a WCF Service. The security requirements are as follows: the server uses wshttpbinding binding and SSL. Perform authentication and authorization based on ad. The client-side authentication information adopts the username method, and provides custom Verification Based on membershipprovider or usernamepasswordvalidator on the server side. It adopts the usewindowsgroups method provided by windows and is verified by principalpermissionattribute. This authentication and authorization combination is used. the built-in authentication methods such as membershipprovider of net cannot meet the requirements of the system, because the built-in authentication only provides a prompt that the verification fails. for specific reasons, such as the username or password is empty, either it is incorrect, the user has been locked, or the password has expired. Therefore, I re-implemented an Active Directory based membershipprovider and defined the exception types for various reasons for verification failure. This membershipprovider works very well, but cannot be compatible with the authorization part. This is the binding setting of the server:

 
<Wshttpbinding> <binding name = "wshttpsbinding" maxcompute edmessagesize = "6553600"> <reliablesession ordered = "true" enabled = "true"/> <security mode = "transportwithmessagecredential"> <transport clientcredentialtype = "NONE" proxycredentialtype = "NONE" Realm = ""/> <message clientcredentialtype = "username"/> </Security> </binding> </wshttpbinding>
 

This is the setting of Service Behavior:

 
   
    
     
      
     
    
  ... 
   
    
     
      
      
        
     
     
     
    
   

After selecting clientcredentialtype as username, you can select the Authentication Mode on the server side based on username, membershipprovider, or windows or custom. If membershipprovider is selected, windowsidentity information cannot be found in servicesecuritycontext. Current, which means that during verification, membershipprovider does not write windowsprincipal information to servicesecuritycontext. Since principalpermissionattribute only depends on the Windows mode, membershipprovider + usewindowsgroups cannot work together. Then I adjusted usernamepasswordvalidationmode to custom:

 
<Usernameauthentication usernamepasswordvalidationmode = "Custom" customusernamepasswordvalidatortype = "testbase. myusernamepasswordvalidator, testbase" includewindowsgroups = "true"/>
 

Customusernamepasswordvalidator can also work well, but it faces the same problems as membershipprovider. However, if you change usernamepasswordvalidationmode to Windows, the authorization can work well:

 
[Principalpermission (securityaction. Demand, role = "builtin \ Administrators")] Public String getdata (INT value ){}
 

This is really unpleasant! I have to use the custom authorization mode:

 
<Serviceauthorization principalpermissionmode = "Custom" roleprovidername = "myroleprovider"/>
 

I don't need to re-implement authorization at all. Because our system performs authentication and authorization based on ad, this is simply an extra action. In fact, in the usernameauthentication configuration item usernamepasswordvalidationmode, authentication and authorization can be separated, but the dependencies between them are obviously not completely removed, which is not impossible. I don't know whether our system security requirements are special, or whether the WCF needs to be improved here. Thank you for your attention.