B# .NET Blog

Role-based security unleashed

Every .NET developer should (at least) have heard about role-based security. In this fourth episode of my "Personal Security Push" I'll talk about what role-based security is all about, how it works and how to empower it in your applications.

What is it?

Roles should build the bridge between the security built in in your code and the physical company structure (think of HR). It tells the code who can perform what action. In real life, your organization likely has various "roles", such as management, consultants, clerks, etc. These people all have different rights and therefore they need different access rules when performing actions in your application. The .NET Framework supports this by means of "role-based security", in which people are associated to their role. and security is applied based on that role. Typically you'll find roles useful to enforce business rules.

About authentication and authorization

In order to use an application, a user needs to do (either implicitly or explicitly) several things to get started. The first action is typically authentication. Authentication is a mechanism for the user to prove that he/she is really who he/she pretends to be (think of passwords, smartcards, fingerprints, eyescans, RFID identification, etc). In order to make this possible, the user and the system need to share a secret in order to be able to validate the user. When authentication succeeds, the system can examine the users database (whatever format it has, Active Directory, SAM, SQL Server, etc) possibly in combination with other repositories (AD/AM, AzMan, SQL Server, etc) to determine the roles for the user. As an example, Windows authentication uses the SAM or Active Directory to associate the groups with a user on logon (combined with privileges this results in the user token that can be queried via the whoami command). On the authentication phase has completed, authorization comes into play throughout the lifetime of the user's session, to determine whether the user has the appropriate rights (based on the user's identity and/or the roles of the user) to perform certain actions (e.g. access the filesystem, make changes to a database, or on a higher level, to perform certain business actions).

IPrincipal and IIdentity

The .NET Framework supports role-based security via the System.Security namespace in general. More specifically, there are two protagonists in the System.Security.Principal namespace that are crucial in the whole story:

• System.Security.Principal.IPrincipal: once the user has been authenticated, a principal for the user is created, which contains the user identity (IIdentity in property Identity) and the roles (method IsInRole) that the user belongs to; depending on the authentication type, a certain implementation of this interface is used (e.g. WindowsPrincipal for Windows authentication, GenericPrincipal for custom authentication)
• System.Security.Principal.IIdentity: the principal also contains information about the user himself/herself, i.e. the user's name and flags about the authentication type and a boolean indicating whether the user was authenticated or not (to detect anonymous users in an application, see Episode 3 on null sessions)

If it helps you, you can take a look at the principal as it were the managed equivalent of a user token, but it contains less information.

Assign the roles to a user

When using Windows authentication, the roles assignment for a user is performed automatically, based on the Windows groups the user belongs to. When accessing the WindowsPrincipal object you can query the roles of the users via the IsInRole method. When using forms authentication, you can use the GenericPrincipal object to represent the user:

FormsIdentity id = ...; //retrieve the identity in some way, e.g. by using FormsAuthentication.Decrypt on the authentication cookie
GenericPrincipal gp = new GenericPrincipal(id, roles); //roles is a string array with the roles
Context.User = gp;

Typically, you'll execute this kind of code after authentication or on Application_AuthenticateRequest event handler in global.asax. As complete example can be found on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT04.asp.

Use the roles in ASP.NET

Once the roles are present, you can use these roles to make decisions about the user rights. In ASP.NET as possible way to do this is by using the web.config file:

<authorization>
   <allow roles="role1" />
   <allow roles="role2" />
   <deny users="*" />
</authorization>

Combined with the location tag, you can grant only specific roles access to certain parts of the website:

<location path="/admin">
   <authorization>
      <allow roles="admin" />
      <deny users="*" />
   </authorization>
</location>

However, this is only the tip of the iceberg. In any kind of application, you can use the role-based security on the code level as well.

Declarative Security versus Imperative Security

Both on the class level and the member level (method, property, delegates, etc) you can apply declarative security. Declarative security is attribute-based (defined in System.Security.Permissions) and fairly straightforward:

[PrincipalPermission(SecurityAction.Demand, Role="SomeRole")]
public class MyClass
//...

or on the member level: