5

I'm working with custom software here, so don't worry about Microsoft whatever, Open anything, or something else. Let’s stick to theory of how this should go together.

Let’s say I have a user system/database.

The database has a table of users, and their associated user-groups (Admin, IT support, Manager, Secretary, client, guest). These aren't hierarchal, but rather memberships to groups. For instance, Alice can be an Admin and Client if need be.

Permissions to an application are assigned to the group, and in the case of multiple-group assignment to a user, the permissions form a simple binary OR of rights (i.e., Admin has X, Guest has Y, then the user gets X and Y).

Applications are a way to do things in an application, they bar access or allow for it. For instance, you have access to "StackExchange" but only to Read -- or you get access to post, or moderator tools, etc...

So to recap, users get groups which govern what rights they can access.

The concept I'm having trouble with is locking down specific records to the user group, especially if we're working across multiple applications. So, for instance, only Admin group can view some posts in the "StackExchange" application.

I don't want to have to add rights to every record, and I don't want to make redundant application code with a minor change.

How would you approach this?

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Incognito
  • 5,204
  • 5
  • 27
  • 31
  • You don't want to add rights to every record, but you want to have access rights for each record? I get the jist of what you are saying, but maybe you can clarify? – Steve Apr 29 '11 at 16:31
  • I want to lock out indicated records, across multiple applications, rather than add an extra field or something to the table with the data which stores the groups. – Incognito Apr 29 '11 at 19:07

3 Answers3

4

Beside ACLs another common approach is to use rules. So you don't define the rights on a per record level but based on characteristics of records.

BaseRight: read postings

Rules: postings with x upvotes, posting created by current user, all postings

Those rules consists of a name and some program logic. They can be very flexible, for example fragments of SQL queries. In the software I develop at work, even administrators can define new rules.

The actual rights are now a combination of base rights and rules with optional parameters.

I recommend to default to no access and to avoid negative rights because it makes the implementation a lot easier and therefore less error prune: You can simply iterate over all rules and as soon as one rule says "okay", you are done. For obvious reasons special care has to be taken when this is done in SQL, but the performance improvement on queries with huge results sets may be worth the trouble.

Examples

For example the anonymous user pseudo role may get this right:

Right: read high quality postings based on

  • BaseRight: read postings
  • Rules: postings with x upvotes
  • Parameter: x=3

A site admin will get this right:

Right: read all postings based on

  • BaseRight: read postings
  • Rules: all postings
Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • I would definitely use rule-based access control as the author here suggests. The authoritative standard for that today is either XACML - authorization-centric - or using a business rules engine – David Brossard Aug 03 '14 at 18:57
3

It sounds like you want to have some records restricted to certain groups, and some (most?) records unrestricted.

Since another way of saying unrestricted is 'everyone has access' it sounds like you need to add the concept of a group called 'everyone', which all users of the system belong to.

Then you can explicitly or implicitly permission the unrestricted records as being accessible to the 'everyone' group.

frankodwyer
  • 1,907
  • 12
  • 13
  • Would this not require me adding the group to each individual record? I'm interested in doing restrictions as an inclusive model, rather than everyone. – Incognito Apr 29 '11 at 17:29
  • you could add the group to every record, which means the code doesn't have to handle any special cases. alternatively you could treat a record with no group as 'everyone' (though this is not nice as it breaks 'deny by default'). – frankodwyer Apr 29 '11 at 18:18
  • Right, I get that, but like I stated in the question I want to find a way where I don't have to add rights into every record. – Incognito Apr 29 '11 at 19:06
  • That's why I suggested having a rule for a record with no rights, i.e. to treat records without permissions as being accessible to everyone, i.e. an implicit permission rather than an explicit one. As I said in the answer permissions can be implicit or explicit. – frankodwyer Apr 29 '11 at 19:58
2

I am not sure there is any getting around having a per resource permission table.

  1. Have a resource table that is indexed by a resource id.
  2. Have a role table indexed by a role id.
  3. Have a users table indexed by a user id.
  4. Have a permissions table that references the above keys.

It adds some overhead but with the correct data types it should be quick to query even with large data sets.

getahobby
  • 175
  • 3