Role-based security is a form of user-level security where a server doesn't focus on the individual user's identity but rather on a logical role she is in. This can be implemented many ways. One way is to simply install some local groups on the server machine that represents roles. The server application can then look for these group SIDs (WhatIsAGroup) and make security decisions based on the groups’ presence or absence. For example, if special privileged access to the server is restricted to members of the Admins role, a local group called APP_NAME_Admins can be created to represent that role.
What's nice about this simple role-based architecture is that it simplifies life for both the developer and the administrator because both rely on well-understood and solid operating system mechanisms to implement security. The administrator uses the tools built in to Windows to add users (and possibly domain groups) to the application's roles (which are themselves simply local groups on the server machine), and the server program relies on the Windows operating system to provide authentication and authorization information via Kerberos (WhatIsKerberos). The server program reads these details in the resulting token it gets for the client (WhatIsAToken). The easiest way to do this is by calling the IsInRole method on the WindowsPrincipal representing the user. This principal object can be obtained in many ways, but most well-written server-side plumbing such as ASP.NET make it visible via Thread.CurrentPrincipal (WhatIsThreadDotCurrentPrincipal). In a simple desktop application, don't bother with Thread.CurrentPrincipal, which is really only necessary for server applications. In a desktop app, you can get a WindowsPrincipal for the user running your application with one line of code.
IPrincipal WhoIsRunningThisApplication() {
return new WindowsPrincipal(WindowsIdentity.GetCurrent());
}
Some systems like COM+ (HowToImplementRoleBasedSecurityForAManagedCOMApp) and Authorization Manager (WhatIsAuthorizationManager), and even SQL Server, provide their own role-based infrastructure, so it's not necessary to create groups. But the idea is the same.
One thing to notice about a role-based system is that it's not as granular as an ACL-based system (WhatIsACLBasedSecurity). Security in role-based systems is centered around the user, not around the particular object the user is trying to access. But this also means it's less complex (count how many items in this book relate to ACL-based security and how many relate to role-based security!). There's something to be said for simplicity in secure systems, but let me defer to Ferguson and Schneier (2003):
There are no complex systems that are secure. Complexity is the worst enemy of security, and it almost always comes in the form of features or options.