Take the 2-minute tour ×
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.

Which approach makes most sense to use, the destructive one or the non-destructive one? Does anyone have real-world experience with one, both or even a different approach?

Model

A permission scheme has a set of permissions linked to it. It can also have a parent from which it inherits permissions.

Destructive

Taking away permissions from a parent scheme also takes away those permissions in any child scheme.

Reason to use this: when later re-enabling those permissions for a parent scheme, they are not automatically re-enabled for child schemes.

Reason to not use this: accidently taking away permissions from a parent scheme means the permissions for child schemes have to be restored separatly.

Non-destructive

Taking away permissions from a parent scheme has no effect on child schemes. The parent and child schemes are combined to determine the correct permissions.

Reason to use this: accidently taking away permissions from a parent scheme does not require the child schemes to be restored separatly.

Reason to not use this: when later re-enabling those permissions for a parent scheme, they are automatically re-enabled for child schemes.

share|improve this question
1  
You've already listed all pros and cons. Use the scheme that has the best rating when you multiply them with the vector of priorities for your situation - we can't do that for you. –  Kilian Foth Jan 19 '12 at 12:40
    
If there are no other pros or cons then we'll have to determine this ourselves indeed. Should I leave this question up, or delete it? –  Stijn Jan 19 '12 at 13:05
    
@Stijn Don't delete it... Give it about a week, and if there aren't any answers... Or revise it to ask a bit more, or give us a better idea of your specific priorities (so we can help choose). –  Yannis Rizos Jan 19 '12 at 13:06
    
In our case we give clients access to our system by creating superusers. Those superusers then are responsible for managing their own users. I'll leave it up for a week then. –  Stijn Jan 19 '12 at 13:13

2 Answers 2

up vote 2 down vote accepted

It is a very complex question and there is no best universal solution, usually each implementation chooses the best approach according to its own specific needs.

I would recommend reading more about Role Based Access Control theory to get a better understanding and bigger picture of the impacts of each specific implementation.

Here is a list of sources you can find useful:

  1. "The NIST Model for Role Based Access Control: Toward a Unified Standard"
  2. "RBAC Standard Rationale"
  3. Wikipedia RBAC overview
  4. Kim Cameron's Identity discussion blog: http://www.identityblog.com/

As one of the approaches I can suggest is to manage your permissions/roles through groups membership. Each user can be assigned to any group.. each role can be assigned to any group. This will decouple roles from users and give you flexibility of adding/removing users without influencing others' permissions.

share|improve this answer

Normally what I have seen done is a combination of both in the following manner:

  • Parent scheme has a set of permissions
  • Child scheme has a set of permissions of which a subset is inherited from a parent.
  • If Child specifies a particular permission in its scheme the childs setting takes precedence over anything that might be inherited from a parent.
  • If Child doesn't specify a particular permission then the setting for this permission will be inherited from a parent.

Thus what will happen is that if the permission you are changing in the parent is used by the child without override you will override the permission for the child.

But if the child has it's own value for the particular permission the change in parent will have no effect on the child.

share|improve this answer

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.