TRANSFER ACTION

[Felicity Vaughan]

Does anyone know how to restrict the Transfer action using ESI?  We ONLY want to restrict the transfer.  We do not want ANY developers to have access to perform the Transfer action.  Any thoughts would be greatly appreciated.

------------------------------
Felicity
------------------------------

[John Scott]

Hello Felicity,

You can do this by adding a name equates for ACTION_INITIATION (Format 4) to define a new security profile format in
your BC1TNEQU table which includes the MENUITEM so you can check for it being TRANSFER.

You likely already have an ACTION_INITATION (Format 4) profile that is tested when you request any Endevor action.
If this profile does not already include MENUITEM then you can create another ACTION_INITIATION (Format 4) profile by including something like this in the BC1TNEQU table:

NAMEQU ACTION_INITIATION,
CLASS='£ENDEVOR',
WARN=NO, (DEFAULT)
LOG=NONE,
L1=('NDVR'),
L2=('ACTION'),
L3=(SYSTEM),
L4=(SUBSYSTEM),
L5=(MENUITEM)

Now when you do an Endevor action and include //EN£TRESI DD SYSOUT=* in the JCL to see the ESI trace you will see an extra format 4 check

ENCS101I Class=£ENDEVOR Log=NONE Func=TRANSFER
ENCS101I Scale=0....+....1....+....2....+....3....+....4
ENCS101I Entity=NDVR.ACTION.FINANCE.PAYROLL.TRANSFER
ENCS101I User FELICITY access is allowed from SAF
ENCS101I RACROUTE RC=0000 RACHECK RC=0000 Reason=0000

You also need to create the RACF profiles to allow or disallow the action taking into account FUNCEQU setting further up in the table that defines level of access require by the user to the profile being tested for the action.

So you would need security to set up RACF profiles/ACF2 rules with levels of access to groups of users who can and cannot do the TRANSFER

NDVR.ACTION.FINANCE.PAYROLL.TRANSFER (G)
NDVR.ACTION.FINANCE.PAYROLL.MOVE (G)

[Giovanni Creato]

Just adding on top of what already indicated by John.

Make sure you already have a section NAMEQU ACTION_INITIATION that uses the MENUITEM keyword => This way Endevor will be prompting SAF for  actions privileges, including TRANSFER. If you don't have this already, make sure to evaluate the impact to the wider system!

Consider elevating the level of privilege required for the TRANSFER action, in the example below I instructed Endevor to require SAFAUTH=CONTROL for the TRASNFER action (normally, I would have required SAFAUTH=UPDATE).

         FUNCEQU SAFAUTH=READ,                                         X        
               C1ACTNS=(DISPLAY,...)                                            
         FUNCEQU SAFAUTH=UPDATE,                                       X        
               C1ACTNS=(ADD,UPDATE,...)                                        
         FUNCEQU SAFAUTH=CONTROL,                                      X        
               C1ACTNS=(TRANSFER,...)                                           

Only those with ACCESS=CONTROL to the profile constructed using the ACTION_INITIATION rule will gain access to the TRANSFER action.

P.S. Note that users may still find a way to achieve the same outcome of a TRANSFER action without having access to it... afterall a TRANSFER is not much different from a RETRIEVE from the "FROM" location and a "ADD/UPDATE" or "MOVE" to the "TO" location ;-)

Regards

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

[Eoin OCleirigh]

John and Giovanni - were quick off the mark and probably have everything you need - the likely key is MENUITEM, but I like Giovanni's suggestion to use a higher SAFAUTH, as this might require less change to your current rules, unless you are already using CONTROL /ALTER for something else like Signout override.  But I'd like to offer three more suggestions/considerations...

a) Please include an EN$TRESI, and maybe EN$TROPT in your post as it will help us all see your current config, have you already got MENUITEM? have you already got two ACTION_INITIATIONs, what SAFAUTH levels are already in play? etc.

b) There are some ENCOPTBL options you might want to check, but just searching ENCOPTBL for "Security", "ESI" and "Transfer" especially in the latest version of this element <iprfx>.<iqual>.CSIQSRC(ENCOPTBL), as a lot of work was done to clean up and clarify the comment text. But in particular checkout:

 - SEC_MOVE_TARGET - can help make rules more consistent

 - SEC_ALTERNATIVE_MENUAUTH - The big one, and needs careful consideration to determine impact on the security package rules (including the intriguing possibility of limiting MOVE without DELETE behind)...  Great write up and table in the source.

  - SEC_RETRIEVE_WITH_SIGNOUT. not related to transfer specifically, but worth considering especially if you need to free up a SAFUATH space

  - PKG_ELEMENT_LOCK=(ON,Y) - while not ESI, might allow greater control of the target location

  - IMPLICIT_DELETE_APPROVAL_CHECK - again not explicitly for Transfer, but can add a check for implicit deletes

  - ALLOW_NON_PKG_ACTIONS - check the value if coded, doesn't allow TRANSFER outside a package (value '32')

  - PACKAGE_ACTION_NO_APPRVR - ditto

c) I recommend you really question, what's going on here, WHY are developers using TRANSFER?  What issues are they trying to avoid/work around? As Giovanni pointed out, just restricting transfer, will not stop users achieving the same basic outcome, if they have access, just maybe in a more roundabout way (and likely error prone).  Some valid use cases might include: Transfer is also Endevor's generic "RENAME" so if users are employing it to fix a mistaken element or type name, a transfer can help them fix it, and preserve the history and avoid the risk when they try to delete the old one.  Are folks using transfer, instead of parallel paths? to jump over elements that aren't ready to promote, if so maybe the answer is another environment/path, or maybe have a look at dynamic environments. Encouraging QuickEdit use might also help keep folks from even looking at the 'batch transfer' and wondering "what's that for..." But also if there is a real, need you might be able to package it as a QuickEdit User Extension point so they can do what they need safely, Maybe they need something like the git stash, or blame... just "automated it" in a safe way.  In the end educating the users, is likely to yield dividends.

d). Oops one, more - if you still need to restrict TRANSFER, then an EXIT might be a cleaner/simpler way to go, especially if the ESI runs, and security resources are already complex.

Cheers,

Eoin

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Roberta Jones]

Felicity - Instead of doing all of this on the communties it would be much easier if you opened a case.  I would be more than happy to assist you with this.  Please do not put any of your tables or traces into the post.  If you need further assistance please open a case. 

Thanks. Roberta 

------------------------------
Roberta Jones
Sr. Principail Support Engineer
Endevor Broadcom Support
------------------------------