Access Control List (ACL) abstraction layer in .net

Question

Is there an ACL abstraction layer available in .net? I have seen some "best practices" documents but no good base implementation. What about the System.Security.AccessControl? Is this a good starting point?

The ACL's should work with Roles stored in DB as well as Roles by the system and for in-memory-object definitions as well as db objects or files. So it should be generic and/or easy to extend.

Should this rely on IPrincipal, IIdentity from the .net framework?

Zend has something similar in their Framework for PHP and I am searching this kind of stuff for C# instead of porting that (if there is already a standard solution or best practice implementation).

@ladislav:

It is not intended to be used only in web services, fat clients or standalone apps. Because of this I am searching an abstraction layer that can be extended by adapters for a specfic backend/platform. You're right, that I am searching something like a role based access management abstraction layer for different kind of objects and right definitions. This should not rely onto the ACLs you set for folders in filesystems. A filesystem should be a special adapter used by the ACLs implementation. For me, ACL itself is a concept and has nothing to do with filesystems. Filesystems USES an implementation of the concept of ACL (even if its mostly known in this field). The hard dependency onto Win32-api is not wanted. This is why I am asking for something generic and abstract (interface) that is commonly (and widely) used. Do you know the implementation in the zend framework (I know it is PHP but the concept works for any app, not only web based)? It is abstracted and could be used for any object in the code

Unloosen

What is problems do you have with System.Security.AccessControl? – Affirmatory

I have seen AccessRule<T> but did not found useful sample code. The msdn is missing some examples in this field, I think. nacl.codeplex.com seems to be a solution but I don't know whether it is commonly used or not. – Unloosen

... maybe a field of usage is gaining access to a specific part of the ui independently from the data rights. A simple string based user/role/objectToAccess would be a starting point. This could be extended in later milestones with growing user demands/requirements (e.g. to use db-backed store or windows user). I don't want a hard dependency to Files/Folders or Active Directory. (I know, I could use a seperate folder to symbolize the objects an do the magic on the fs but I don't think this is a good idea.) – Unloosen

You should clearly describe in your question what are you want to do and what type of application are you building. Be aware that .NET is not only about building web applications so not every feature available in .NET is related to what you expect. The namespace you mentioned is tightly coupled to Windows - I expect it is wrapper of Win32 API to manipulate ACLs in Windows. What you are looking for is probably called Role based security and in case of web application Membership provider and Role provider. – Roryros

@ladislav: Is it completely coupled or only the default implementations? I don't agree with your statement. There are some samples for IPrincipal and IIdentity in microsofts all code samples library at codeplex. But you're right if you say most implemented (given) classes are tightly coupled to specific fields (like fs or web). – Unloosen

IPrincipal and IIdentity are two core interfaces to do any authentication / authorization in .NET. Combine them with PrincipalPermission + PrincipalPermissionAttribute and you can build anything you want but perhaps there are ready to use solution (I'm not aware of them except those I already mentioned). – Roryros

@ladislav: Thanx for the info. It would be nice if .net contains a simple type-independent (using object or generic type) base implementation. – Unloosen

Answer 1

An example abstraction is the library nAcl - .NET Access Control List

... "helps you handle scenarios for a matrix of rights easily. It can also be easily extended through a Provider" ...

Features:

• Handles the rights of an application for you
• Handles a hierarchy of rights
• Rights are calculated in one place but can be potentially retrieved from anywhere thanks to the provider mechanism (seems to be a relevant feature to add several sources)
• In memory provider for static rights
• Router provider to handle routes and associating providers to a route
• Sql provider to handle rights in Db

... but I haven't seen the usage of IPrincipal within the Interface.

Unloosen