When using Windows authentication, using the Windows user group security subject permission mode is a good choice. You can directly use existing user group settings, or create separate user groups for corresponding applications or services. However, because this mode depends on Windows authentication, it means that this mode can only be used in LAN environments. If you use the ing between certificates and Windows accounts, it can also be applied to external network environments such as B2B. In other network environments, Windows user group-based authorization methods are powerless. In addition, there is also a situation where, even in the same LAN environment, Windows is also used for client authentication, but we do not want to create too many Windows user groups, instead, the user's permission information is maintained in the corresponding database and maintained through a separate security system. In this case, the authorization mode based on the ASP. NET role management module is a good choice.
Directory:
I. ASP. NET Roles provider
Ii. ASP. NET Roles authorization and authentication independence
3. Set ASP. NET Roles authorization in ServiceAuthorizationBehavior
I. ASP. NET Roles provider
Like Membership, Roles is also an important ASP. NET provider designed to maintain Roles and grant role-based permissions. ASP. NET Roles also adopts the policy design mode. The role addition, deletion, acquisition, and authorization functions are defined in the abstract class System. Web. Security. RoleProvider. ASP. NET provides three specific roleproviders by default. They also reflect three different storage formats of role and authorization information. If they do not meet your specific authorization requirements, you can also customize RoleProvider. For example, if the database you are using is Oracle, you can refer to SqlRoleProvider to customize a OracleRoleProvider.
- SqlRoleProvider: stores role and authorization information in the predefined table of the SQL Server database;
- Window#enroleprovider: The Windows user group is used for authorization. This is a read-only RoleProvider. Adding and deleting roles (user groups) is not allowed;
- AuthorizationStoreRoleProvider: uses the Authorization Manager (AzMan) library for role storage.
ASP. NET Roles-related functions can be basically done by calling the corresponding method of the static class Roles. The following code snippet lists the main Roles methods. CreateRole and DeleteRole are used to create and delete roles. The RoleExists user determines whether the specified role exists. The AddUser (s) ToRole (s) and RemoveUser (s) FromRole (s) it is used to establish and remove the relationship between users and roles. IsUserInRole is used to determine whether a specified user has a corresponding role.
1: public static class Roles
2: {
3: // other members
4: public static void CreateRole(string roleName);
5: public static bool DeleteRole(string roleName);
6: public static bool DeleteRole(string roleName, bool throwOnPopulatedRole);
7: public static bool RoleExists(string roleName);
8:
9: public static void AddUsersToRole(string[] usernames, string roleName);
10: public static void AddUsersToRoles(string[] usernames, string[] roleNames);
11: public static void AddUserToRole(string username, string roleName);
12: public static void AddUserToRoles(string username, string[] roleNames);
13:
14: public static void RemoveUserFromRole(string username, string roleName);
15: public static void RemoveUserFromRoles(string username, string[] roleNames);
16: public static void RemoveUsersFromRole(string[] usernames, string roleName);
17: public static void RemoveUsersFromRoles(string[] usernames, string[] roleNames);
18:
19: public static bool IsUserInRole(string roleName);
20: public static bool IsUserInRole(string username, string roleName);
21: }
For the Roles method AddUser (s) ToRole (s), it is worth mentioning that the four methods do not verify the existence of the user account. The reason is simple. The management of user accounts belongs to the scope of Membership, and the relationship between users and roles is the responsibility of role management. Membership and Roles are two independent providers for ASP. NET. They do not have any dependency. You can use ActiveDirectoryMembershipProvider to manage and authenticate user accounts using AD, and maintain roles in SQL Server data tables based on SqlRoleProvider. In this case, when we call the AddUser (s) ToRole (s) method of Roles, the specified user account does not exist in the database. Therefore, Roles does not verify whether the user exists or not. It is only responsible for adding the specified user name to the corresponding role. This independence of Membership and Roles is also reflected in WCF.
Ii. ASP. NET Roles authorization and authentication independence
Through the previous introduction, we clearly know that Windows User Group authorization depends on Windows authentication, but if you use ASP. NET Roles Security subject permission mode. You can use any non-anonymous client creden。 and authentication methods. That is to say, the ASP. NET Roles mode truly reflects the independence between authentication and authorization.
Under the ASP. NET Roles Security subject permission mode, a RoleProviderPrincipal object is created and used as the current thread security subject. The Identity of the RoleProviderPrincipal is the same object as the PrimaryIdentity attribute of the current ServiceSecurityContext. The uniformity of the two can be reflected through the following verification procedures.
1: IIdentity identity1 = Thread.CurrentPrincipal.Identity;
2: IIdentity identity2 = ServiceSecurityContext.Current.PrimaryIdentity;
3: Debug.Assert(object.ReferenceEquals(identity1,identity2));
In principle, as long as the authenticated user name can correctly obtain the list of Roles that reflect permissions through ASP. NET Roles, authorization can proceed smoothly. If you use Windows authentication (including the three cases mentioned above), you need to assign roles to Windows accounts (Domain Names/usernames. If Membership-based and Custom-based user name/password authentication is adopted, the user name and role will be allocated directly. If you use a certificate that does not allow Windows Account ing, the authenticated user name is a combination of the certificate subject name and fingerprint (<topic name >;< <fingerprint> ), you need to set permissions (roles) here.
3. Set ASP. NET Roles authorization in ServiceAuthorizationBehavior
As mentioned before, all programming based on security subject authorization is reflected in ServiceAuthorizationBehavior's service behavior. To enable WCF to use ASP. NET Roles for authorization, we need to set the PrincipalPermissionMode attribute of ServiceAuthorizationBehavior to PrincipalPermissionMode. UseAspNetRoles, and specify a specific RoleProvider for its RoleProvider attribute. As for RoleProvider acquisition, you can get the default RoleProvider through Roles's Provider. In addition, Roles has a Providers attribute similar to the dictionary type to return the list of roleproviders for all configurations. You can pass in the configuration name to obtain the corresponding RoleProvider.
>
1: public sealed class ServiceAuthorizationBehavior : IServiceBehavior
2: {
3: // other members
4: public PrincipalPermissionMode PrincipalPermissionMode { get; set; }
5: public RoleProvider RoleProvider { get; set; }
6: }
7: public static class Roles
8: {
9: // other members
10: public static RoleProvider Provider { get; }
11: public static RoleProviderCollection Providers { get; }
12: }
The following is a piece of Self-hosted code. Before enabling ServiceHost, we specify a ServiceAuthorizationBehavior behavior for the service, and set its security subject permission mode to PrincipalPermissionMode. UseAspNetRoles. This ServiceAuthorizationBehavior uses the default RoleProvider currently configured.
1: using (ServiceHost host = new ServiceHost(typeof(CalculatorService)))
2: {
3: host.Authorization.PrincipalPermissionMode = PrincipalPermissionMode.UseAspNetRoles;
4: host.Authorization.RoleProvider = Roles.Provider
5: host.Open();
6: //...
7: }
We recommend that you configure service authorization settings as always. In the following configuration section, we configure a unique RoleProvider of SqlRoleProvider type under the <system. web>/<roleManager> node. The configuration name of this SqlRoleProvider is sqlRoleProvider, and the connection string name of the target database is aspNetDb. ServiceAuthorizationBehavior is configured in the service behavior configuration section named aspNetRolesAuthorization. The principalPermissionMode attribute that reflects the Security subject permission mode is set to UseAspNetRoles, while the roleProviderName attribute is the name of the configured RoleProvider.
1: <configuration>
2: <connectionStrings>
3: <add name="aspNetDb" connectionString="..." providerName="System.Data.SqlClient"/>
4: </connectionStrings>
5: <system.web>
6: <roleManager enabled="true" defaultProvider="SqlRoleProvider">
7: <providers>
8: <add name="sqlRoleProvider"
9: type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
10: connectionStringName="aspNetDb" applicationName="AspRolesAuthorizationDemo"/>
11: </providers>
12: </roleManager>
13: </system.web>
14: <system.serviceModel>
15: <services>
16: <service name="Artech.WcfServices.Services.CalculatorService" behaviorConfiguration="aspNetRolesAuthorization">
17: <endpoint address="http://127.0.0.1/calculatorservice" binding="ws2007HttpBinding"
18: contract="Artech.WcfServices.Contracts.ICalculator"/>
19: </service>
20: </services>
21: <behaviors>
22: <serviceBehaviors>
23: <behavior name="aspNetRolesAuthorization">
24: <serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="sqlRoleProvider"/>
25: </behavior>
26: </serviceBehaviors>
27: </behaviors>
28: </system.serviceModel>
29: </configuration>
Source: http://www.cnblogs.com/artech/archive/2011/07/04/asproles01.html