Standard for defining user rights?

[oliver]

Hello,

I need to define user rights for the application I work: what is which
user allowed to do? I looked at the Java policy stuff, but it is too
complicated and too effortful for what need to get done. I'd actually
prefer to define a database table where to define the rights. So why
don't you do that? Just wanted to ask whether there is any kind of
standard or framework made exactly for defining user rights as I
couldn't find anything on the Internet.

Regards, Oliver Plohmann

 

[zero]

(e-mail address removed) wrote in @o13g2000cwo.googlegroups.com:

Hello,

I need to define user rights for the application I work: what is which
user allowed to do? I looked at the Java policy stuff, but it is too
complicated and too effortful for what need to get done. I'd actually
prefer to define a database table where to define the rights. So why
don't you do that? Just wanted to ask whether there is any kind of
standard or framework made exactly for defining user rights as I
couldn't find anything on the Internet.

Regards, Oliver Plohmann

You don't really need a framework. Unless you want very tight security,
all you need to do is use JDBC to read the permissions - it's no more than
5-10 lines of code.

 

[Chris Smith]

I need to define user rights for the application I work: what is which
user allowed to do? I looked at the Java policy stuff, but it is too
complicated and too effortful for what need to get done. I'd actually
prefer to define a database table where to define the rights. So why
don't you do that? Just wanted to ask whether there is any kind of
standard or framework made exactly for defining user rights as I
couldn't find anything on the Internet.

The closest thing to a standard is JAAS. Unfortunately, it's difficult
to use JAAS in realistic applications. In fact, the whole security
model that was enshrined by JAAS has been responsible for permission-
impoverished J2EE applications leading to IT departments dictating poor
business processes for nearly half a decade now.

So, forget JAAS or make limited use of it, and write your own code.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sam]

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

 

[Andy Dingley]

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]

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.