C# 4 and .NET 4

authentication and authorization ❘ 547
The output from this console application looks similar to the following lines; it will vary according to your
machine’s configuration and the roles associated with the account under which you are signed in:
IdentityType:System.Security.Principal.WindowsIdentity
Name: farabove\christian
'Users' True
'Administrators' False
Authenticated: True
AuthType: NTLM
Anonymous False
Token: 416
It is enormously beneficial to be able to easily access details about the current users and their roles. With
this information, you can make decisions about what actions should be permitted or denied. The ability
to make use of roles and Windows user groups provides the added benefit that administration can be done
by using standard user administration tools, and you can usually avoid altering the code when user roles
change. The following section looks at roles in more detail.
roles
Role-based security is especially useful in situations in which access to resources is an issue. A primary
example is the finance industry, in which employees’ roles define what information they can access and what
actions they can perform.
Role-based security is also ideal for use in conjunction with Windows accounts, or a custom user directory
to manage access to web-based resources. For example, a web site could restrict access to its content until
a user registers with the site, and then additionally provide access to special content only, if the user is a
paying subscriber. In many ways, ASP.NET makes role-based security easier because much of the code is
based on the server.
For example, to implement a Web service that requires authentication, you could use the account subsystem
of Windows and write the web method in such a way that it ensures the user is a member of a specific
Windows user group before allowing access to the method’s functionality.
Imagine a scenario with an intranet application that relies on Windows accounts. The system has a group
called Manager and one called Assistant; users are assigned to these groups according to their role within
the organization. Say that the application contains a feature that displays information about employees that
should be accessed only by users in the Managers group. You can easily use code that checks whether the
current user is a member of the Managers group and whether he is permitted or denied access.
However, if you decide later to rearrange the account groups and to introduce a group called Personnel
that also has access to employee details, you will have a problem. You will need to go through all the code
and update it to include rules for this new group.
A better solution would be to create a permission called something like ReadEmployeeDetails and assign it
to groups where necessary. If the code applies a check for the ReadEmployeeDetails permission, updating
the application to allow those in the Personnel group access to employee details is simply a matter of
creating the group, placing the users in it, and assigning the ReadEmployeeDetails permission.
declarative role-based security
Just as with code access security, you can implement role-based security requests (“the user must be in the
Administrators group”) using imperative requests by calling the IsInRole() method from the IPrincipal
class, or using attributes. You can state permission requirements declaratively at the class or method level
using the [PrincipalPermission] attribute:
using System;
using System.Security;
using System.Security.Principal;
using System.Security.Permissions;
www.it-ebooks.info