Re: User Security Advice

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?

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

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

James Rich

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