User groups/roles for application

[pritaeas]

We're in the process of upgrading/improving our application framework, and we're currently looking into (application) user groups and roles. We want to implement CRUD rights to our screens. What's in place is a kind of ORM, so there's a class for each table already. Am just looking for ideas on how to get this built as generic as possible.

[Ketsuekiame]

A general, generic system would have you define a table to store your groups, a table to store what permissions that group has and a table to assign users to groups.
I would then translate that into C# and assign roles to your screens.
The other option is to be more database driven and record the permissions for each screen as a table. Personally, if you're doing simple CRUD permissions I would use interfaces and mark your screens.

ie. MyScreen : IRequiresWrite, IRequiresRead

Otherwise if you need to make it more complicated;

MyScreen : IRequiresPermissions

And then load the permissions required from the DB

You would need to write your own middleware for the permissions authentication. I'm not sure of anything out of the box.

[pritaeas]

You would need to write your own middleware for the permissions authentication.

No problem, they want control anyway.

I would use interfaces and mark your screens

All screens would need all four (CRUD), it depends on the role a user's in whether he's allowed. So how would you map a role to a screen. Using database is fine. Are you thinking about storing the screen class name mapped against one or more roles?

[Ketsuekiame]

Are you thinking about storing the screen class name mapped against one or more roles?

Or use attributes. But the attributes would have to match your DB permissoin names and any changes would have to be retrospective too...

[pritaeas]

Well, roles would have to be set/defined on application level, so I don't think attributes would work.

[Ketsuekiame]

In that case no, your only real option is to match the Ids of your screens to the roles required, in your DB.

[pritaeas]

Suppose a screen shows a master detail relation. Would it make sense to connect a screen's right to rights on the underlying tables? Company and contact relation for example: I define that the screen uses both classes (tables). Using such a setup I can extrapolate that logic to buttons for example. A button can be visible for the aforementioned screen, but it's action may need rights to something else entirely (create an invoice for that contact for example).

[Ketsuekiame]

If you interfaced it out, you could easily check the permissions of screens below the parent. Alternatively you could go action based and link your roles to actions rather than screens. This would probably require more maintenance but give you more flexibility.

[pritaeas]

Alternatively you could go action based and link your roles to actions rather than screens.

Makes sense, because 'view screen X' is triggered from somewhere. Action based sounds okay, food for thought. Perhaps I need to find a way to combine this with rights on the class/table somehow.

[pritaeas]

Action based sounds like a good start, so if anybody knows of some interesting samples please let me know.

In addition, we probably want to define visibility of specific properties, for example to hide financial information. Not sure yet if we'll define that in the database, or categorize them by using attributes. Any samples on this appreciated too.