Role Management
Role-based Security Facts
The table below describes three role-based security terms you should know.
| Security Term | Description |
| Identity | Analogous to a Windows user. The identity includes the user name and is used to reference the role and permissions of each user. |
| Role | Analogous to a Windows group. Used to reference the permissions of a group of users. |
| Principal | A Principal object encapsulates a security context, including user name, role, and permissions. |
In .NET, role-based security includes the process of checking a user’s authentication information against the roles (or permissions) that the user is assigned. It is up to the programmer to enforce role-based security in the application.
The table below describes the four class and attribute implementations upon which role-based security relies.
| Implementation | Description |
| Identity Classes | Identity classes inherit from the IIdentity interface and keep track of the username, whether the user is authenticated, and the authentication type used. |
| Principal Classes | Principal classes inherit from the IPrincipal interface. They reference the user Identity and include methods for getting the roles membership for the user. There are two principal classes in the .NET libraries: WindowsPrincipal and GenericPrincipal. |
| PrincipalPermission Class | The PrincipalPermission class allows programmatic security checks to be made. Use methods in this class to identify whether users have the necessary permissions to gain access. |
| PrincipalPermissionAttribute | Use the PrincipalPermissionAttribute to tag assemblies, classes or class members. The user of the assembly, class or member must have the permissions specified in the attribute tag. |
Identity and Principal classes represent passive objects; they simply encapsulate user and permission information. PrincipalPermission and the PrincipalPermissionAttribute are active objects; they perform the security demands when appropriate.
The following table lists several methods and properties available through these classes.
| Class | Members | Description |
| Identity Classes | AuthenticationType Property | Indicates the type of authentication used (for example: Basic, NTLM, Kerberos, etc.). |
| IsAuthenticated Property | Indicates if the user is authenticated. | |
| Name Property | Stores the username | |
| Principal Classes | Identity Property | References the IIdentity object associated with the IPrincipal object. |
| IsInRole() Method | Returns true if the associated IIdentity object is in the specified role. | |
| PrincipalPermission Class | Demand() Method | Throws a SecurityException if the current principal does not match the PrincipalPermission instance. Note that this is the method that you use to enforce security using the imperative model. |
| Intersect() Method | Returns a new PrincipalPermission object that is the intersection of the calling object and the object passed in. Calling Demand on intersected PrincipalPermission objects has the effect of requiring the current user to be authenticated by both PrincipalPermission objects. | |
| Union() Method | Returns a new PrincipalPermission object that is the union of the calling object and the object passed in. Calling Demand on unioned PrincipalPermission objects has the effect of requiring the current user to be authenticated by either of the PrincipalPermission objects. |
The exact mechanisms you use to implement security depends on whether you will be using imperative or declarative security. The following table shows implementation examples of each approach:
| Implementation Method | Description | ||||||||||||||
| Imperative Security | The imperative method of implementing security uses the PrincipalPermission class and involves placing the security calls directly in the program code. The following example creates a PrincipalPermission object and demands to know if the DEMO/demo is a member of the User role.
try
{
PrincipalPermission permissions =
new PrincipalPermission("DEMO/demo", "User");
permissions.Demand();
// If the user is a member of the role,
// additional statements will run
}
// If the user is not a member of the role,
// an exception will be thrown
catch(SecurityException ex)
{
// Actions based on invalid security credentials
}
Note that the following using statements are presumed to be included at the top of the file for the example: using System.Security; using System.Security.Permissions; |
||||||||||||||
| Declarative | Declarative security involves placing attributes on the assembly, class or class member you wish to protect. Use the PrincipalPermissionAttribute to tag assemblies, classes or class members. The user of the assembly, class or member must have the permissions specified in the attribute tag.
[PrincipalPermissionAttribute(
SecurityAction.Demand,
Name="DEMO/demo",
Role="User")]
public void SecureProcess()
{
// The code will only be executed if
// the security checks are passed
}
The actual parameter, which you must pass to the attribute constructor, is the SecurityAction you wish the attribute to enforce. SecurityAction.Demand enforces the same level of security as the Demand method of the PrincipalPermission class. The named parameters in the above example set the Name and Role which the permission requires in order to execute. The following table describes the members of the enumeration.
|