Tuesday, October 24, 2006

Active Directory and User Roles

The WinForms app I'm working on has two modes: edit and read-only. It's all or nothing: either you can edit everything or you can edit nothing. If you're not allowed even read-only access you can't run the app.

So I am faced with the challenge, familiar to many of you, of providing read-only vs. edit access in a nice, clean way. There's an article by Irena Kennedy called Granular Role Based Security Without a Line of Code: Attribute-Based Authorization that I really like. It uses attributes to indicate default values to be set for object properties based on their authorization to specific actions in Authorization Manager. I like this idea. I could put something in a post-InitializeComponent method in my form base class that ran through the controls declared in its descendant and set default properties based on the role membership of the user.

But I'm using AD and WinForms. So how do we shoehorn AD groups into the Identity, Principal, and Role model? The user's groups seem obvious choices for roles, but the WindowsIdentity object already has its own collection of groups. I thought about loading the AD groups of each user into the Roles collection of a GenericPrincipal, but it seems counter-intuitive to replace an authenticated WindowsPrincipal with an unauthenticated GenericPrincipal.

So I was thinking about turning around and heading in the opposite direction. Maybe I should create Attributes that didn't pretend to be other than AD-specific: IsInGroupAttribute(string groupName, string propertyName, object defaultValue) and maybe NotInGroupAttribute(string groupName, string propertyName, object defaultValue). When processed by the initialization routine we would just do an AD lookup (cached, of course) and check group membership.

Go on, tell me why this is a bad idea.


Post a Comment

<< Home