Security Based on Access Control Lists (ACLs) focuses more on objects than on users (as opposed to role-based security, discussed in WhatIsRoleBasedSecurity). The idea in an ACL-based system is that each object will have its own access control policy represented by a list of permissions stored in an ACL (WhatIsAnAccessControlList). Whereas a role-based system might control whether a user in a particular role may access a set of objects in a certain way, an ACL-based approach allows each individual object to control which users can touch it and in what ways. An object typically grants permissions to groups (WhatIsAGroup), and an ACL-based access check requires comparing the requesting user's groups to the permissions granted in the object's ACL.

This leads to more complexity than in a role-based system, but also allows for finer-grained control. When there are millions of objects, each with its own ACL, something needs to be done to simplify the management of these ACLs. In Windows this comes in the form of ACL inheritance, which I discuss in WhatIsACLInheritance.

Windows uses a discretionary, ACL-based approach to securing objects, such as files, registry keys, services, and kernel objects such as processes and threads. What this means is that the discretionary ACL (DACL) for any given object is controlled by whoever creates the object (this user becomes the object’s owner). Ownership is a very interesting property that not enough developers are familiar with, so I recommend reading WhatIsOwnership to get a better feel for what it means. To learn more about discretionary access control, check out WhatIsDiscretionaryAccessControl.

In a simple desktop application, you don't have to write any code to take advantage of ACL-based security. The operating system performs access checks each time a program opens a secured object such as a file (for example, the FileStream constructor will throw an exception if this access check fails). This is because the operating system ensures that each process has a token (WhatIsAToken) representing the user on whose behalf the process is running, and this is visible to the operating system each time the process makes a system call.

In a server application, things are a bit itdifferent. ACL-based security is still in force, but you've got to remember that your server application will be assigned a token based on how's configured. If you configure the server to run as Bob, you'll have a token for Bob and so all access checks for your process will be based on Bob's permissions rather than on those of his client. If the server wants to use his client's credentials to access a secured resource such as a file, it should impersonate the client before opening the file. But impersonation is not something to be taken lightly, so read WhatIsImpersonation to learn more about it.

Whereas role-based security is an optional feature that usually requires writing some code (as shown in HowToTrackClientIdentityUsingThreadDotCurrentPrincipal and HowToImplementRoleBasedSecurityForAManagedCOMApp), ACL based security is always present and really quite transparent to most applications.

PortedBy PeterJausovec