ESP - GETFILE protection ehnancement

[Jonas Dusil]

Dear ESP community,
We are happy to announce the release of an enhancement LU12226, introducing new SAFOPTS parameter GETFILE.
The new parameter allows ESP to perform an additional SAF resource check for GF.dsname security profile.
The GF.dsname security profile restricts access to the data sets that can be requested in ESP Workstation Client.

Please refer to techdocs.broadcom.com for more details:
New Features
Create Security Profiles
SAFOPTS: Define host security options
SAFOPTS Command: Control Processing Options

------------------------------
Jonáš Dusil
Product Owner | ESP Workload Automation | Mainframe Software Division
------------------------------

[ERIC Foecking]

Jonas, welcome new feature.  Please clarify if there is any distinction in using the new feature vs. using RACF dataset controls.

Currently, we will grant access to an application dataset mask such as

HLQ.applpfx.** (UPDATE)

that would grant update access to update access to the PROCLIB, JCLLIB, SYMLIB, etc. for the mapped group.  Will the new feature replace that requirement or enhance it?  Would one method be preferred over the other?

Thanks,

 

------------------------------
[Company]
------------------------------

[Lucy Zhang]

Hi Eric,

You should not consider this new ESP security profile as a replacement for your current dataset control profile. 

This ESP GETFILE security profile will add another layer of checking when the requests are from ESP workstation. 

In the scenario that ESP GETFILE allows the requests, but the dataset control profile doesn't allow it, then the requests will still fail with the errors from the dataset control profile.

Hope this helps,

Lucy

[Juraj Dusicka]

Hi Eric,

The new control method is applied in addition to the existing check of the DATASET security profile and is related only to access to a dataset via 'Browse Data Set' and 'Edit Data Set' functions in Workstation Client. Moreover, this new control method is turned off by default and needs to be turned on specifically. 

So a user with UPDATE DATASET access to the HLQ.applpfx.**. would be denied access only in case if the new SAFOPTS parameter GETFILE is set and the user is trying to update the dataset using 'Edit Data Set' function in Workstation Client and has no UPDATE authority to the ESP security profile ESP.GF.HLQ.applpfx.**.

Hope that answer your question.

Juraj

[ERIC Foecking]

Thank you Lucy and Juraj - your clarifications help.  One other point, it appears the GF.dsname can be set to READ or UPDATE (or blank/none by omission) but UPDATE will allow the creation, and I assume deletion, of the given dataset IF aa corresponding RACF dataset control DOES NOT exist.  Would it not be reasonable/appropriate to add the Security product level appropriate to doing a create/delete as an option?

------------------------------
[Company]
------------------------------

[Juraj Dusicka]

The Workstation Client 'Edit Data Set' function doesn't support any dataset deletion. As for the dataset creation, it only supports creation of a new PDS member in an already catalogued PDS dataset. It is not possible to create a new sequential dataset using the 'Edit Data Set' function in the Workstation. So actually we're considering only adding a new PDS member here, in this case the security product (it does not depend on the security product used) either allows a user to create a new PDS member in a catalogued PDS dataset or not. And the GF.dsname security profile would just add an another layer of checking for the same when the user attempts to create the PDS member using the Workstation Client 'Edit Data Set' function. 

Juraj

[ERIC Foecking]

Thank you for the clarification!

 

------------------------------
[Company]
------------------------------