By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,729 Members | 1,178 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,729 IT Pros & Developers. It's quick & easy.

An addition to my userlevel problem.

P: n/a
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

Jul 17 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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

Jul 17 '05 #2

P: n/a
Jay Moore <ad*****@isp.tld> wrote in message
news:<rx*******************@twister.rdc-kc.rr.com>...

My heirarchy looks like this:

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. .... 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.


OK, let's say that each user has a permission string that consists of
numeric (possibly, zero-filled) strings delimited by dashes. The first
such string (required) would denote the client, the second (optional),
business, the last (again, required), the user. Whatever is in-between,
reflects hierarchy and hierarchy alone.

So, if you have a user whose permission string is 0001-0001 (that
would be your client number one), that user would be authorized to
access anything that has permission string 0001-* (that is, everything
that has to do with client number one). If you have a user whose
permission string is 2479-1876-4765-2678-0634 (something like "client
2479, business 1876, business unit 4765, business subunit 2678, employee
ID 0634), that user would be authorized to access anything that has
permission string 2479-4983-4765-2678-*. Needless to say, user with
a permission string of 2479-0001 would be allowed to access anything
that has permission string 2479-*, including, of course things with
permission string 2479-4983-4765-2678-*.

Since this is a string, it allows for indefinitely deep nesting of
levels, and the maximum possible ID number at each level is MAXINT.

I understand this is really awkward, but this is the only solution
I can think of given the variable depth of your problem...

Cheers,
NC
Jul 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.