Role-Based Security: ACLs and Role Hierarchies

  • Thread starter Thread starter Liet Kynes
  • Start date Start date
L

Liet Kynes

I'm new to the .NET security framework, and I pose the following questions:

1) According to the documentation I've read .NET is promoting a role-based
security model centered around IPrincipal. What about granular user-based
security requirements? For example: I'm building a file repository app that
allows users to upload files to the application and share them with specific
users and groups/roles. Suppose we have three roles (officer, manager, and
employee). An officer uploads a sensitive document to which only officers
are privy...with the exception of a single manager. This manager cannot
simply be moved into the officer role, since he should not be privy to all
files that officers can see. Is this a scenario that can be supported by the
..NET Security model, or will I have to "roll my own" permissioning framework
for this? It seems to me that each file would have to have its own ACL that
contained roles and users.

2) Is the concept of role hierarchies supported? Extending the example
above, officers should be able to see all files, managers see a subset(s),
and employees see a subset(s) of that. Is this supported, or do I have to
explicity call .IsInRole for every group individually?

I'd appreciate any insight or pointers to more resources.

Liet
 
Liet,
If you implement your own IPrincipal derived class then you can also extend
it with extra methods that are useful for you. And in this case you will
have to cast your IPrincipal object to your extended class whenever you want
to call your custom methods. Notice that generally speaking (ie. unless you
change security settings) your should be able to set any IPrincipal
implementation to the HttpContext.Current.User (or other principal slot if
your app isn't a web app). IPrincipal tries to give you what would suffice
the majority of the Apps without extra complexity.

However, I think you don't even need to do what I mentioned above for the
scenario described by you, I think only IsInRole will give the granularity
your app is demanding. For example, remember that you can call IsInRole many
times from within a boolean expression. Please see the pseudo-code below
(not compiled, just from the top of my mind):

public bool CanAccessOfficerFile(string fileName, IPrincipal
currentPrincipal)
{
if (currentPrincipal.IsInRole("Officer") ||
currentPrincipal.IsInRole("FILE:" + fileName)) return true;
return false;
}

Using this approach. You can assume that you have 3 general roles (Officer,
Manager, and Employee) but, for exceptional situations, you would create the
special roles "FILE:*", so that regardless of the general roles that a user
may have, they can always access a file if they have the explicit special
file role (named FILE:SomeFilenName). The special file roles should be
created on demand by your app. In other words, they should be very few if
they are created only when needed. On the other hand, if these special roles
are becoming too frequent then your general categories (Officer, Manager,
and Employee) don't seem to reflect your general case and therefore you will
have to re-think what is your common case.

--
Thanks.
Paulo

DISCLAIMER: This posting is provided "AS IS" with no warranties, and confers
no rights. Use of any included code samples are subject to the terms
specified at http://www.microsoft.com/info/cpyright.htm"
 
Back
Top