C# fine-grained permissions: multiple internal systems, intranet scenario

Question

Hello all,

I have the following scenario:

• Multiple users (< 100)
• User accounts in AD (under different groups)
• Every group in AD corresponds to a internal department; each department have at least one supervisor
• (One may say) We have cross-supervisioning (there are supervisor roles appliable to group of groups, i.e., there may be one supervisor that actually supervises three or for groups - as existent in AD)
• Multiple internal systems, half of them web-based, all of them built over .Net framework

Currently we have most of desktop-based systems authenticating users by folder permissions (deployed in network environment using ClickOnce, each deployment folder permissioned by individual users). That does not work for all desktop systems, though; we have two of them using their own embedded authentication system, as follows:

• System A consists basically of different datatables (just shows some data in the screen).

• All of the datatables are actually different groupings of the same data; this data refers to specific account.

• Every account row contain the columns {number, owner, type, data1, data2, data3, data4 ...}; the different groupings are based on number/owner/type.

• All of the data(n) columns are numbers (the sum for each grouping is displayed when grouping is done)

For this specific system, the data columns are attributed to groups. So, users in AD Group1 can see columns data(1-5), Group2 can se columns data (7-9) and so on. However, supervisor for each group can see one extra column for their group (supervisor of Group1 can see data(1-5) and data6 - lets call it "special column" for the group); there are supervisors who can see other groups columns (either including the "special column" or not), there are general supervisors who can see all of the columns and there are also users who can see all of the non-special columns. It's a mess.

In order to solve this problem ClickOnce is not enough; so basically what the dev team did was to embed a particular authorization assembly, which queries a database using the current system as a parameter (it supports other systems) and returning a set of column names as results; these results are then used in another query that retrieves only the specific user columns.

This legacy system is about to be replaced by a newer one; after a lot of consideration (including maintainability - the system architecture is a mess), since it's just about data retrieval and displaying with minimal processing we decided to use (some of) the queries and re-write the data retrieval logic.

On top of that, most of the existing web-based systems are hard-code permissioned (if (sADLogin == "userA") {..}); a few of them only rely on ultra-non-intuitive URLs sent to specific users and fingers crossed. Sad.

We'd like to use a more abstract approach for permission (so we can make every system use the same authentication provider). Using web services/WCF just seems appropriate (also considering that I still have to authenticate desktop-based systems and some spreadsheets, maybe using monikers); however I couldn't find an adequate pattern or architecture model for it. There is one WCF Intranet pattern in Microsoft documentation that solves most of it - except that I can't use my Windows Groups as roles. There is an Internet pattern (http://msdn.microsoft.com/en-us/library/ff650091.aspx), however, that seems to handle the roles problem (that's what I'm going with right now), but since it's my first time dealing with WCF security I'd like to have some expert opinions on this matter.

Any ideas?

Thanks,

Answer 1

For web-based applications, this can be simply solved with single-signon to Active Directory using the built-in ASP.NET Provider Model (see: http://msdn.microsoft.com/en-us/library/aa478948.aspx). You can use Active Directory for authentication, and domain groups for authorization. There are several built-in ways you can limit access to pages (using tags in web.config), access to certain parts of a page (using ), and access to code (using User.IsInRole() or RolePermission attribute) - that all works automatically. For web, this is sort of the standard (internet or intranet).

For non-web-based applications, you can actually still use features of that same provider model. You can also pretty easily look up group membership in Active Directory.

If all you need is to know what groups someone is in, this is probably how you should do it. If instead, that database table you have, has something more complicated (like delegation authorization), then yeah - you may want to throw a WCF service in front of that, and have all your applications use that. However, in the case of ASP.NET, I'd STILL use the provider model, and just write my own RoleProvider, so I could still use all the built-in features of the ASP.NET security. Hope that helps.