Jay Moore wrote:
If any of you happened to read my earlier posts, I had a dilemma with
creating an efficient method of limiting access to data for my users and
subusers.
My heirarchy looks like this:
[Please excuse my shoddy ASCII art ;)]
Admins
|
+- Client 1
| |
| +- Business 1
| | |
| | +- Operator 1
| | |
| | +- Operator ..
| | |
| | +- Operator n
| |
| + Business n
| |
| +- Operators ...
|
+- Client n
|
+- Business n
|
+- Operators ...
What I need to do is find a way to associate data entered with a certain
group so that only that group may perform actions on it.
For example: Operator 1 is associated with Business 1 which, in turn,
is associated with Client 1. If Operator 1 enters in some data, that
data should only be accessible by members of the Business 1 group and
groups above it ( Admin > Client 1 > Business 1 > Operator 1 ). This
would be done in such a way that data is shared 'up' but not 'across'.
Data entered by a member of Business 1 would be accessible by other
members of Business 1 but not by Business 2. Moving up a tier, Client 1
would have access to all his businesses, but not the businesses of other
clients.
There would be a bevy of different clients and businesses so saying,
"Well, make Admins = 1000, each client a multiple of 100, each business
a multiple of 10, and each operator a multiple of 1." The obvious
problem with that would be when there are more than 9 of any client,
business or operator.
So, now I beg of you wise, wise people: How on earth do I construct a
heirarchy and tagging system to do what I described above? I'm certain
something like this has been done before. I am just unaware of how to
set it up.
TIA,
Jay
Hi Jay,
First, sorry, I didn't catch you followup question. I forgot to mark
that thread as one I was involved in.
To mimic a UFS file permission scheme, you'll need to store your data
with the following information:
User Owner
Group Owner
Permission Set (three octets)
The user owner is a specific user that has the most basic access to any
resource. In most cases, the user owner is allowed to do absolutely
everything to their resources. However, it's sometimes practical to
limit a owner's abilities to manipulate (or destroy) a certain resource.
The group owner is the primary group that "owns" the file. Typically,
this is set to the group to which the owner belongs. This allows you to
create a group-wide permission assignment.
Lastly, the permission set allows you to set the permissions for read,
write, and execute for three levels of users:
1. Users
2. Groups
3. Everyone Else
In your proposed system, I would create a group for each logical group
of users:
-Admins
-Clients
-Businesses
-Operators
Within each group, you're allowed to have as many members as you want.
Additionally, any user can belong to any number of groups (as per UFS
conventions). So, in your DB, you would want to create a linking table
that would link the group table to the user table and allow a
"many-to-many" relationship.
So in your example, I would then create a couple users with these
attributes:
Admin1: Belongs to Admin
Admin2: Belongs to Admin
Client1: Belongs to cl1
Client2: Belongs to cl2
Business1: Belongs to bu1
Business1: Belongs to bu2
Operator1: Belongs to bu1
Operator2: Belongs to bu1
Operator3: Belongs to bu2
Operator4: Belongs to bu2
Admin1 and Admin2 are also members of cl1,cl2,bu1,bu2
Client1 is also a member of bu1
Client2 is also a member of bu2
Then, your resources can have these attributes:
report1 Operator1:bu1 640
report2 Operator2:bu1 640
report3 Operator3:bu2 640
report4 Operator4:bu2 640
Therefore, report1 can be read by anyone belonging to the bu1 group and
changed only by the user Operator1. This means that users Client1,
Business1, Operator1, and Operator2 can all read the report (including
the Admins, of course).
As you can see, the multi-tier hierarchy can be carried out simply by
assigning proper groups (and subgroups). If you need more complex
schemes, just assign more groups including and excluding members as you
need.
As the developer of the project, I would create a "super user" for
myself to use. On UFS schemes, the super user is not restricted by the
permission schemes and can always read and write any file.
Let me know if you need any further help. (You can also email me
directly if your followups start to get into the particulars of your
implementation.)
HTH,
Zac
