Configure ESI to allow/restrict "MOVE" and/or "ADD/UPD" independently

[Charles Gaskell]

Currently we have the following Function authorization equates:

 FUNCEQU SAFAUTH=NONE,                                          
       C1ACTNS=(SIGNIN,PBACKOUT,PCAST,PCOMMIT,PCREATE,PDISPLAY, 
       PEXECUTE,PLIST,PMODIFY,PREVIEW,PSHIP,PUTILITY,PDYNAMIC,  
       ALTER,SIGNOUT)                                           
 FUNCEQU SAFAUTH=READ,                                          
       C1ACTNS=(DISPLAY,RETRIEVE)                               
 FUNCEQU SAFAUTH=CONTROL,                                       
       C1ACTNS=(ARCHIVE,DELETE,MOVE,SIGNOVR)                    
 FUNCEQU SAFAUTH=UPDATE,                                        
       C1ACTNS=(ADD,GENERATE,UPDATE)                            
 FUNCEQU SAFAUTH=ALTER,                                         
       C1ACTNS=(ENVRNMGR)                                       

and the following name equate for action initiation:
NAMEQU ACTION_INITIATION,                                      
      CLASS='DATASET',                                         
      WARN=NO,  (DEFAULT)                                      
      LOG=NONE,                                                
      L1=('<pseudo hlq>'),                                             
      L2=(ENVIRONMENT),                                        
      L3=(STAGENAME),                                          
      L4=(SYSTEM),                                             
      L5=(SUBSYSTEM),                                          
      L6=(ELEMENT)  

We have a requirement that some people are allowed to ADD elements into a particular Environment, stage 1, but are not allowed to MOVE them to stage 2, and some people that are NOT allowed to ADD elements into a particular Environment, stage 1, but are allowed to MOVE them to stage 2 (and some people that are allowed to do both actions, and other people that are not allowed to do either action).

How do I achieve this using ESI?  For this instance, we are using ACF2 (if that makes a difference).

I set up an ACF2 rule that gave READ and ALLOCATE but not UPDATE to the pseudo-dataset mask, but got this when I tried to do the MOVE
Format=0004 Pass=0000 Auth=CNTL ACEE=00000000 C1BM4210 XMOVRUTN+003794
Class=DATASET  Log=NONE   Func=MOVE                                   
Scale=0....+....1....+....2....+....3....+....4....+....5....+....6   
Entity=<hlq>.<env>.<stg>.<sys>.<subsy>.<ele>                               
User XXXXXX   access is denied   from SAF                             
RACROUTE RC=0008 RACHECK RC=0008 Reason=0000

-------------------------------------------

[Eduard Penafiel Salat]

Hi Charles

Since you need to control who is allowed to move INTO a particular stage, you could try enabling the SEC_MOVE_TARGET option in the optional features table (ENCOPTBL). With this option enabled, the security check for the MOVE action is done twice, once for the source stage and then for the target stage (by default, MOVE checks only for the source stage).

RACF vs ACF2 vs Top Secret doesn't make any difference. In all cases, Endevor will issue a RACROUTE REQUEST=AUTH macro to the security product with the same exact parameters (formatted as per the definitions in the ESI table) regardless of the underlying security product, which will respond to the request based on the permissions granted to the user.

Regards - Eduard

-------------------------------------------

[Charles Gaskell]

Thanks Eduard,

It's the opposite problem I'm having - that the SAF call seems to be denying something I think it should be allowing (though I'm happy to accept that I may be misunderstanding how it's designed to work).

The challenge I am having is that while it is correctly not letting me do the ADD/UPDATE, it is also not allowing the MOVE, even though the rule specifies:
 <environment>.*-.*-.*-.*-    UID(<matching UID>) R(A) A(A) E(A) (i.e. Read, Allocate (i.e. Control), Execute - only Update is denied)

Format=0004 Pass=0000 Auth=CNTL ACEE=00000000 C1BM4210 XMOVRUTN+003794
Class=DATASET  Log=NONE   Func=MOVE                                   
Scale=0....+....1....+....2....+....3....+....4....+....5....+....6   
Entity=<hlq>.<environment>.<stage>.ZZZ.C.RUNSCL                               
User <myuser>  access is denied   from SAF                             
RACROUTE RC=0008 RACHECK RC=0008 Reason=0000                          

When I set the rule to:

<environment>.*-.*-.*-.*-    UID(<matching UID>) R(A) A(A) W(A) 

it works fine (but then allows the ADD/UPDATE action which I'm trying to prevent):

Format=0004 Pass=0000 Auth=CNTL ACEE=00000000 C1BM4210 XMOVRUTN+003794
Class=DATASET  Log=NONE   Func=MOVE                                   
Scale=0....+....1....+....2....+....3....+....4....+....5....+....6   
Entity=<hlq>.<environment>.<stage>.ZZZ.C.RUNSCL                               
User <myuser>   access is allowed  from SAF                             
RACROUTE RC=0000 RACHECK RC=0000 Reason=0000                          

It's almost as though it needs both UPDATE and CONTROL access in order to be able to do a MOVE, not just CONTROL access                    

[Roberta Jones]

HI Charles -

Please open a case and I will assist you.  I please recreate your scenario and send the the full output - I need an ESI trace and options trace.  you can add these dd statements to the batch job: 

//BSTERR DD SYSOUT=*

//EN$TROPT DD SYSOUT=*

//EN$TRESI DD SYSOUT=* 

Thanks Roberta

------------------------------
Roberta Jones
Sr Principal Support Engineer
Broadcom | Mainframe Software Division
------------------------------

[Karen Turner]

Charles,

Refer to the security guide section Map Authorization Values .. you have the Move action assigned to Control.  under ACF2 Control maps to WRITE access not ALLOC, as does UPDATE to  which you have also assigned ADD and UPDATE. Since the user in question does not have WRITE access ot the corresponding ACF2 rule, ACF2 is denying the action. 

You can use the following syntax to test your acf2 rule:

ACF                              
SET RULE                                                     
TEST hlq                                                   
 LID(userid) DSN('<hlq>.<env>.<stg>.<sys>.<subsys>.<ele>')  -   
 ACCESS(UPDATE)                                                

A few options/suggestions:

1) move MOVE and DELETE to ALTER (which maps to ALLOC)

2) if you have no elements that require their own rule, look into changing L6 to MENUITEM then your pseudodsn will reflect

'<hlq>.<env>.<stg>.<sys>.<subsy>.MOVE'  and '<hlq>.<env>.<stg>.<sys>.<subsy>.ADD' and .UPDATE  -   
 

3) If you do need element in your pseudo dsn, and keep your FUNCEQU mapped as is,, consider adding the second ACTION_INITIATION format (what used to be FORMAT5).  this is a second call is made after a successful 1st ACTION_INITIATION call.  you could make it hlq.menuitem and then distinguish between hlq.ADD, hlq.UPDATE and HLQ.MOVE with WRITE access accordingly.

My personal preference would be a combination of option 1 and option 2.

Karen

                                  

------------------------------
Karen
[JobTitle]
[CompanyName]
[State]
------------------------------

[John Scott]

Hello Charles,

This is what we do....

Your action_initiation format being checked is defined in BC1TENQU as follows:

hlq.environ.stage.system.subsys.element

This action initiation format does not include menuitem which Endevor sets MOVE/DELETE/ADD etc

You can include more than one action_initiation format that are to be checked and all need to be allowed to progress.

Leave existing rules and access lists as they are.

Define the second NAMEQU ACTION_INITATION in BC1TNEQU

For example:

hlq.system.subsystem.menuitem

Existing security covers hlq.environ.stage.system.subsys.element

Endevor will do a second check for new format e.g. hlq.system.subsys.menuitem

Endevor will check for the users access to the rules/profiles depending on the action being requested (menuitem)

hlq.FINANCE.PAYROLL.MOVE or hlq.FINANCE.PAYROLL.ADD

You then just need to get these new rules created with the access you want the users to have to the actions.

hlq.*.*.MOVE
hlq.*.*.ADD

-------------------------------------------

[Peter Pravda]

BTW, SAFAUTH=NONE for ALTER sounds super dangerous! Or do you control access to the Alter action in a different way, like through an exit?

As for the main question, Karen and John already provided the proper guidance. Thank you.

Peter

-------------------------------------------