[Tfug] Ideas for handling group based allow/deny permissions?

[Brian Murphy]

Quoting Choprboy <choprboy at dakotacom.net>:
> I'm currently working on writing a document management system for
> storing/distributing docs/pictures/etc. between different people in a
> company....
(snip)
> I am currently trying to figure out how to handle the problem that 
> occurs when users are members of multiple groups and you allow/deny
> members in overlapping groups... Has anyone done something like this
> before and how?

I've worked with many such systems.  You have a fundamental problem of
burning the candle from both sides.  Choose to either grant rights
(preferred) or deny rights.  As it is now, you've created a convoluted
mess.

(read on)
> For instance, consider a company HR document detailing benefits. It 
> applies to all full time employees, but not the commisioned sales
> staff, so you don;t want them to see it. You set the permissions so
> that it is readable by everyone in the "employees" group, but denied
> to anyone in the "sales" group.
> In the following users:
>
> Alice: Marketing coordinator, member of "employees" and "marketing" (etc.)
> Bob: Sales, member of "employees" and "sales"
>
> So Alice gets to look at the document, but Bob is denied... But now think
> about Bob's manager Ted:
>
> Ted: Sales manager, member of "employees" "managers" and "sales"
>
> Ted should be able view the document because he is a manager, but
> because he is part of the "sales" group (because he manages/reviews
> their work) he is forbidden from viewing it... So what to do???

The problem is that your groups are not configured properly.

I would start with a grant only system.  Then grant access to managers,
marketing, and any other group that isn't sales.  Alternatively, if
that non-sales group list is unwieldily, you could create a group that
meets your criteria of "all full time employees, but not the
commisioned sales staff."


(read on)
> I see 2 basic ways around it:
> 1)Do an "allow group && deny group && allow individual && deny individual"
> type security check, which gets combersome to remember "Ted" must be
> specifically allowed every time.
> 2)Make lots of different groups (i.e. "sales", "commisioned-sales",
> "salaried-sales", "part-time-sales", etc.) which gets very cumbersome to
> manage users in all the different groups.
>
> Neither of these approaches handles the "user doesn't understand permision
> AND'ng" problem and I don;t think either handles the scaling to 1000's of
> users problem either. Any other suggestions?


You sort of see the problem here.  The more complex and entangled you
make your system, the less people are going to understand, and
therefore: the less secure your system will be!

A role based system will scale fairly well.  You need to tackle it from
the groups side, not how "clever" you can make the authorization
process.

Brian


The opinions or statements expressed herein are my own and should not be
taken as a position, opinion, or endorsement of the University of
Arizona.