Kinda Tricky Authorization Schema - How to Implement?

DaseinFiasco posted on Friday, March 16, 2007

I am developing a relatively simple application with a complex authorization structure, and am faltering in extending CSLA to meet my requirements. I was wondering if anybody here had some advice. Keep in mind that this is my first implementation of CSLA, so forgive me if I overlook an obvious solution.

 

My authorization schema looks like this.

 

1. An accounts table.

2. A users table.

3. A roles table

4. A join table.

 

The join table relates the users, roles, and accounts tables. i.e. it has the columns UserId, RoleId, and AccountId.

 

The roles table has records like “Guest”, “Researcher”, “Coach”, “Admin”, etc.

 

The end result is that the user might be a “Researcher” and “Admin” under one account, a “Guest” under another, and “Coach” and “Researcher” under another still.

 

What it appears I must do is to extend the authorization so that in addition to checking if a user is a member of a given role(s), I must also check that, for a given business entity, if that entity is related to an account, that the given role(s) is also related to that account.

 

Here’s what I have been thinking, and I would be grateful for any insight as to whether or not this seems to be a viable set of changes to implement my authorization requirements.

 

Create an IAccount interface, that has one member: int AccountId.

 

Override the IsInRole(string role) method in my custom Principal class, and replace the private List<string> _roles object in my custom Identity class with a jagged array of Roles and Account Ids (or some other suitable object). Modify all the other corresponding Identity/Principal implementations of roles to accept AccountId as a parameter.

 

Subclass the BusinessBase (and other base classes), and override the “public virtual bool Can[Read|Write]Property( string propertyName )” such that the method will first check if the IAccount interface is implemented - if (this is IAccount) - and if so, then search the current user’s roles collection attempting to match the AccountId implemented from IAccount with the user’s assigned roles/accounts.

 

Does this sound like I’m generally heading in the right direction? I haven’t written any code to handle this yet, so I may run into scoping problems, etc. But conceptually, are there any other touch-points for roles that I would need to change in CSLA?

 

Thanks for any feedback.

RockfordLhotka replied on Friday, March 16, 2007

Yes, it sounds like you are heading in the right direction. I'll be interested to hear how this works, and if you run into any issues where CSLA doesn't allow you the extensibility to do what you need. I think you should be good to go though.

skaue replied on Wednesday, April 25, 2007

This sounds a lot like what I need to implement in our project. Have you figured this out yet or did you ditch the whole thing and do something else (like play on the xbox 260 instead)