Privilege Management

[Robert Monical <rm...@destinations.com>]

We are writing a specification for an Apache/modperl based data 
entry/update system that will operate against an Oracle database.

I am a Perl/modperl novice.
This will be a lightly loaded Web Server (less then a dozen concurrent 
"sessions", 100s of updates/hour).
Users will log in. I assume that we will use Apache Session and URL 
rewriting to manage user sessions.

Users will have a profile defining which actions are allowable.
Since there are so many cool Perl tools out there, I would like a sanity 
check on our proposed Privilege Management approach.
The number of privileges will start at less than 20 and will certainly 
never grow to more than 50.

-----------------------------
We will have a user table
We will have a table for actions that lists each possible action.
We will have a join table linking users to allowable actions.

Each screen has a defined list of possible actions.  This information is 
"hardcoded" into the entry logic for the screen.
When a screen is sent to the user, the possible action is checked and 
enabled/disabled based on the user privilege.
The maintenance screen for these tables will be in Oracle forms.
----------------------------

Is there a better way?

Thanks!

p.s.  What I would love to see is the ability for each display object that 
links to an action to set it's own enabled/disabled state. Not sure how 
this might be accomplished in a Web environment.


--Robert Monical
--Director of CRM Development
--rmonical@destinations.com

Re: Privilege Management

["Bruce W. Hoylman" <bh...@advtech.uswest.com>]

>>>>> "Robert" == Robert Monical <rm...@destinations.com> writes:

    Robert> Each screen has a defined list of possible actions.  This
    Robert> information is "hardcoded" into the entry logic for the
    Robert> screen.  When a screen is sent to the user, the possible
    Robert> action is checked and enabled/disabled based on the user
    Robert> privilege.  The maintenance screen for these tables will be
    Robert> in Oracle forms.

I would NOT show all actions that are available in the system but rather
only show the actions which client viewing your actions screen has
access to.  In my experience showing all available actions whether
granted to the client or not, tends to give the client 'action envy' and
you will be busy either granting all the actions to the clients they do
not currently have, or explaining why an action is available and they
have not been granted the authority to perform said action.

You can dynamically generate the action list based on the enabled
privileges of a user, and perhaps sock this list into your session
object.

Otherwise, you approach is basic and sound, IMHO.

Peace.