Authorization Mechanisms(认证机制)

The first method is to use the <authorization> section of the Web.config file to control access to files
and folders:

<authorization>
<allow roles=”Members”/>
<deny users=”?”/>
</authorization>

 This configuration only allows the users in the Members role access the files and subfolders of the folder
where the Web.config file is located. The UrlAuthorizationModule automatically uses the contents of
the <authorization> section to authorize the user without any work on the part of page developers. Page
developers are only responsible for using the <allow> and <deny> elements to define the access rules.

The second method is to use the PrinciplePermissionAttribute to control access to classes and
methods:

[System.Security.Permissions.PrincipalPermission(System.Security.Permissions.
SecurityAction.Demand,Role=”Members”)]
public static bool MyMethod()
...{
...
}

The PrinciplePermission demand shown here will only allow members of the Members role to call
the MyMethod method. This means that the PrinciplePermissionAttribute attribute allows you to
create more fine-grained access rules than the <authorization> tag in the Web.config file. The
<authorization> tags can be used to control access to a file, not the classes and methods in the file.

The third method is to use the PrinciplePermission class programmatically to control access to a
block of code:

public static bool MyMethod()
...{
System.Security.Permissions.PrincipalPermission perm =
new System.Security.Permissions.PrincipalPermission(null, “Members”);
perm.Demand();
...
}

Only members of the Members role will be allowed to run the code that comes after the call to the
Demand method.
The fourth method, using the IPrincipal.IsInRole method, allows you to set up even more finegrained
access rules:

public static bool MyMethod()
...{
...
if (HttpContext.Current.User.IsInRole(“Members”))
...{
//some code
}
}

Only the members of the Members role will be allowed to run the code inside the if block.