Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

Imagine a system which has a number of functions and a number of users. A user must have rights to a specific function. Users may belong to a group. A group may belong to a group.

So as a simple illustration, user A has rights to function 1 and 2. User b has rights to function 2 and 3.

User A is in group1 which has rights to function 3, but negative, i.e. explicit denied access to function 1.

For extra complexity, perhaps the function has default rights. So you can say, but default everyone has access to function a, or no one has access to function a. I guess it's the same as having an Everybody group.

So the question is how are you managing user rights? Do you make all rights additive? Do you allow the explicit denied I mention at the end? Do you have a system where the most access possible is granted or the least? Do you make user rights trump group rights, or vice versa?

I've seen a number of variations for applying rights. I'm now defining my own and I'm really looking for any experience you have in that area where you wish you'd done something different, or were delighted you chose a particular way of doing things.

Thanks

share|improve this question
1  
It really depends on your system; your specifications are not entirely clear. You say user A has rights to function 1 and 2, but is also part of group1 which forbids access to function 1. Would that allow him access to function 1 or not? In some situations maybe we would want user rights trump group rights, in other situations we would not want that- we can't know what your exact situation is and what would be best. You first need to define a clear hierarchy for these sort of things; then an ACL like approach would probably be an easy way to solve your problem. – Bitgarden Jul 7 '11 at 23:26
That's really the question. The specification is fluid at this point, it's essentially just "provide rights and security". The question is how best to implement that security model. – Ian Jul 8 '11 at 10:01

2 Answers

up vote 7 down vote accepted

Do you make all rights additive? Do you allow the explicit denied I mention at the end? Do you make user rights trump group rights, or vice versa?

These are really requirements questions. Talk it over with whoever owns the project and discuss the implications with them, then code what you and they decide is best for the project.

Do you have a system where the most access possible is granted or the least?

This is easier to give a solid answer to. The Principle of Least Privilege states that the system is most secure when no one has access to anything they don't actually need. This is a pretty well-understood principle that's been tested in real-world security for decades, and it makes a good guideline to go by.

share|improve this answer
That's pretty much what I'm getting at. As mentioned I've seen it implemented in many ways, all of which work. I'm trying to decide on a scheme which minimises the confusion you can get when assessing why someone could (or couldn't) do something. The principle of least privilege makes perfect sense. – Ian Jul 8 '11 at 10:03
up vote 2 down vote

I make such systems as simple as possible. But at the end it's the customers choice. I would avoid 'negative' rights, since that would be heavily confusing and would need a very well designed interface for administration of rights.

So roughly: Rights add up. If the user is in a group A that has a certain right and in another group B that does not have it, he gets the right thanks to A membership.

If he should not have a right that he would gain by a group, don't make him member of this group.

Default rights:

If everybody has access to function A, you simply don't need any check there and no entry in the table holding the possible rights

If nobody has access to function B, you can save your time coding it, since nobody can use it anyway.

In my practical experience, customers often start with big wishes for complex rights management, only to find out later that they don't want to have to do all the work to handle them. They think they need special rights for every employee, department, freelancers, interns, trainees and whatever. But after working with such a system for a while they want it changed to something simpler. In most cases there are only very few functions that are really important and allow to change relevant data or view personal user data. Those need protection. So most of the time you have an Admin group (can do everything) a customer support group (can view everything, but limited edit) and maybe something for interns (can do a few things like editing content, but can't see customer data or change important things).

But everything depends on the kind of system you are writing, there may be more rights if money is involved or bookings need to be made. But in most cases this can be reduced to at most one group per department.

Keep it simple or people will misuse it by granting Admin rights to everybody and his cat.

share|improve this answer
I totally agree with the customer not knowing what they want. My default position is scepticism. Have you ever had one of those discussions where they keep looking for dubious edge conditions? "Hey what happens if new starter X just happens to be the CEO's son and therefore gets more access than his collegues, but only during an eclipse and ..." – Ian Jul 8 '11 at 10:05
@Ian: No, luckily not to this extend. I think something like subgroups (inheriting rights from parent groups) and negative rights (belongs to group X but without function Y) was the worst regarding to rights management. Though I had many customers with weird ideas about (for example) payment options in webshops (worst case: their customers could have paid twice as everybody else under certain edge conditions, thanks to a strange subscription scheme) – thorsten müller Jul 8 '11 at 10:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.