I am with you. I have struggled with the java.security and
javax.security packages and always end up writing my own. What you
need is these three classes:
User
Role
Permission (or Right)
And the DB corresponding DB tables and table to map a user to his roles
(if he can have more than one and a table to map what Permissions (or
Rights) a role has. They way I have done things is then make the
Pemission be (for example) 0=Can't see 1=Read 2=Write 3=Delete
So when a user logs on, you look up his roles, grab all his Permissions
based on this role and then allow him to do or see things based on a
specific Permission. So User has a method boolean
hasPermission(Permission p, int level)
Can't tell you how many times I have applied that architecture...
Good Luck
Sam
>What you need is these three classes:
>
>User
>Role
>Permission (or Right)
I'd agree with Sam up to a point.
First of all, get away from "user based rights". It's a really bad idea
to use a system based on "access levels", "admin users" or any similar
hierarchical / ordinal system. Instead your permissions need to be
independent, and your users are granted possession of a set of them - a
set that's potentially different for all users.
If you don't do this, you end up with a hierarchical sequence of "user
levels" where either each one has all the access rights of the ones
beneath them, or else there are far too many user levels required and
you end up with "operators", "operators who can also make backups",
"operators who can also control printers", "operators who can do both
backups and printers". It's an inflexible and over-complex system.
Worst of all, it's an ongoing complexity for your poor bloody users, for
the whole life of the system. Yes, we want to write the simplest code
possible - but not at the expense of a long term hassle for many users.
#include trekkie_spock_quote.h
As to "roles", then I'd disagree with Sam. It's certainly useful to be
able to "place a user within a role", but IMHO this is only a convenient
way of setting up new users. The set membership for rights should be an
attribute of each user independently, not just of the the role (and the
user implying the relevant role). Otherwise we're back to the "four
sorts of operator" problem described above.
In some cases you may have hierarchies of admins controlling the issuing
of rights, not just one level of admins (who could then issue themselves
with ultimate rights and steal the family silver). Then you might even
extend this "role" mechanism so that users do have a "role" which is
permanent, not just a default, and this can control the limits of the
rights they might possibly be allocated. The actual rights within this
permitted set (just which server they can use, whether they can kill
jobs as wel as start them) are much lowlier and can be issued by junior
admins. Creating users in powerful roles (or moving userss between them)
is then a task which only the mightiest of admins are allowed to do.
_But_ we still maintain the actual set of rights as a user attribute,
not just a role attribute.
Sam - 06 Jan 2006 22:14 GMT
I agree with Andy. My post above assumed you had a single role (or the
user picks a single role of his choices for roles, I have done both).
But a third way is what Andy is saying. When a user logs on, take all
his roles and union/combine all the permissions for all his roles so he
has the highest possible access. I have written this way also and
definitely the way I do it when allowed (some customers don't get the
idea of combining Roles). I may not be explaining it well, but a Role
is simply a grouping of Permissions. Then combine all groupings
together when the user logs on to give him the maximum access.