Implementing Role Based Security using C# - Declarative and Imperative Security
(Page 2 of 4 )
The .NET framework allows you to use two different syntax schemes to implement security declarations. Declarative security uses the attribute syntax with security constraints stored in the assembly at compile time. All security constraints can be specified using Declarative security and you can limit access to an entire method. The downside is that tools are available that can extract your security requirements from the metadata in the assembly. An example syntax is:
[PrincipalPermissionAttribute(SecurityAction.Demand, Name=@"myCompany\Emp_Role ")]
With Imperative security you write normal, everyday code, and can restrict portions of a method. This gives you finer granularity and limits the security parameters contained in the metadata (i.e. available to prying eyes). An example syntax is:
FileIOPermission MyFilePerm = new
FileIOPermission( FileIOPermissionAccess.Write, n);
MyFilePerm.Demand();
Role Based Security in Your Code
The .NET framework provides several classes that allow you to access a user’s role or group membership. The classes I’m talking about are: WindowsIdentity, WindowsPrincipal, PrincipalPermission, GenericPrincipal, IPrincipal and IIdentity classes. There are times when you need to explicitly verify a user's role or group membership before a method or section of code is accessed. This is yet another example of the Defense in Depth principle--using multiple layers to secure your application. You can easily configure your application to be accessed only by members of certain roles or groups. But if for some reason this level is compromised, you can provide an additional layer of protection in your code by using the WindowsIdentity and WindowsPrincipal classes.
The WindowsIdentity Class
The WindowsIdentity class represents a user’s Windows account and will let you view the user's name and authentication type, as well as other information about the user. Once you create a WindowsIdentity object you can access several useful properties:
- AuthenticationType – A string representing they type of authentication.
- IsAnonymous - Boolean
- IsAuthenticated - Boolean indicating if the user is authenticated or not
- IsGuest - Boolean
- IsSystem - Boolean
- Name - The user's domain\username
- Token - The user's authentication token
To create a WindowsIdentity object you’ll call one of three methods:
GetAnonymous() - To mimic an anonymous unauthenticated user. This is useful when you’re impersonating an anonymous user.
GetCurrent() - The most common method used to create a WindowsIdentity object. The current user’s name and group membership is returned.
Impersonate() - Used to impersonate a specific user.
The WindowsPrincipal Class
The WindowsPrincipal class provides access to the groups to which a user belongs, and is used in concert with the WindowsIdentity class. To create a Principal object you have to get the current user's identity by creating an object of type WindowsIdentity and passing that to the WindowsPrincipal constructor. Like this:
WindowsIdentity curIdentity = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrincipal = new WindowsPrincipal(curIdentity);
You can also do this by querying the current thread (as usual there’s more than one way to perform a task). First make sure the principal policy is set to use Windows Security; then you can create a WindowsPrincipal object. Like this:
AppDomain.CurrentDomain.SetPrincipalPolicy
( PrincipalPolicy.WindowsPrincipal );
WindowsPrincipal myPrincipal = (WindowsPrincipal)
Thread.CurrentPrincipal;
Next: Now you have a WindowsPrincipal Object. So what? >>
More C# Articles
More By Victor Stachura
/ 17 
