Re: User Security Advice

[James Rich <james@xxxxxxxxxxx>]

On Thu, 21 Sep 2006, Al Mac wrote:

> I suggest expanding the PF design to house some code representing
> application such as General Accounting, or specific areas of Accounting,
> such as General Ledger, that the relevant dept head may want to limit
> different people different kinds of access different areas.  So you have a
> code like A* for Accounting, AG for General Ledger.  Develop this for all
> applications.  Include IT dept e.g. accessing Security itself.  Instead of
> a set of flags for ALL programs, you have ALL application areas, with room
> for some growth.
>
> So basically for an application like General Ledger, you'd have some codes
> representing major activities ... is this person allowed to delete old
> journals, are they allowed to update journals, can they see critical
> accounts like owner's equity.  You come up with a set of access rules by
> application manager desires, and recognize the software may not be
> structured to permit this set of rules to be implemented immediately, but
> what you are doing is designing the security file to support reasonable needs.

<snip>

> In front of EVERY program you'd have a CL to call the security checking
> routine.  It have parameter saying "I am accounting or whatever granular
> area" and to run me people need whatever security classification.  This
> routine returns a YES GO or NO STOP flag to the calling program.  If the
> result is NO, it might also send a MESSAGE to a security message queue ...
> such and such a user tried to run whatever software but did not have the
> proper clearance.  This would be reviewed by the relevant dept managers to
> say whose security and what programs ought to be adjusted to different
> security settings.
>
> Can people access this stuff without going thru the front door menus,
> particularly the security file itself?  Does this stuff need to be encrypted?

We do something similar to this, though we use service programs instead of 
CL to prevent anyone from ever bypassing the security check.  We wrote a 
subprocedure called getappauth() which optionally prompts the user for a 
password and checks a file that contains flags for the application being 
accessed.  The key to this file is application,user.  the subprocedure is 
documented at:

http://www.eaerich.com/docs/era-api.html#getappauth

if you are interested.  The flags are specific to each application. 
getappauth() returns a pointer to the flags, so the number of flags 
returned can be expanded without having to recompile the service program 
or any of the other programs that use it.

A program that uses getappauth() is coded basically like this:

D* First define some consts which simply are used to indicate
D* what kind of permission we are asking for
DNOTESREVISE      C                   CONST(1)
DNOTESADD         C                   CONST(2)
DLOCK             C                   CONST(3)
DDELETE           C                   CONST(4)
D*
D*  checkauth
D*    Check authorization levels for specific tasks
D*
Dcheckauth        PR                  LIKE(ERA_bool)
Dtask                            4S 0 VALUE
D*
Dauthdata         S             51A
Dauthpointer      S               *   inz(%addr(authdata))
C* (authlevel is ignored in this example)
C                   clear                   authlevel         2
 /free
   eval error = getappauth('<appname>':TRUE:80:authlevel:authpointer);

   // We use checkauth() to interpret the flags returned by getappauth()
   // making our code more obvious as to what it is doing:
   if (checkauth(DELETE) = TRUE);
     // do the delete
   else;
     // send some kind of message
   endif;
 /end-free

And the checkauth() subprocedure looks like this:
Pcheckauth        B
Dcheckauth        PI                  LIKE(ERA_bool)
Dtask                            4S 0 VALUE
D*
D* Define a DS that receives the flags returned by getappauth()
D                 DS
Drevisenotes              1      1A
Daddnotes                 2      2A
Dlockdoc                  3      3A
Ddeletedoc                4      4A
Dauthds                   1     51A
C*
C                   move      authdata      authds
 /free
   select;
     when (task = NOTESREVISE);
       if (revisenotes = 'Y');
         return TRUE;
       endif;
     when (task = NOTESADD);
       if (addnotes = 'Y');
         return TRUE;
       endif;
     when (task = LOCK);
       if (lockdoc = 'Y');
         return TRUE;
       endif;
     when (task = DELETE);
       if (deletedoc = 'y');
         return TRUE;
       endif;
   endsl;
   return FALSE;
 /end-free
Pcheckauth        E

Constants like TRUE and FALSE are defined elsewhere and have their obvious 
meanings.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw