Implementing security in a multisystem environment

In a multisystem environment, Strobe allows a user to submit a request from one system that will run on, or relates to measurements on, another system.

Example
  • A user can issue a request from system A to measure a job that is currently running on system B.
  • A user can issue a request from system A to target a measurement session for several systems where the designated job may subsequently run.
  • A user can issue a request, such as CHANGE or LIST, from system A that is directed to a measurement session that is running on another system or is targeted to multiple systems.

Security Database Recommendation

Strobe access filter processing in a multisystem environment includes authorization checks against the security database of the system on which the request is entered and the system on which the request runs. If the authorization check fails on the system where the request is entered, Strobe issues a warning message and allows the request to proceed. If the authorization check fails on the system where the request is supposed to run, the request is rejected.

We recommend that all systems with members in a Strobe XCF group have the same security database. Similarly, if you disable the access filter on one system, you should disable it on all systems in the Strobe XCF group.

Task 3.8.1: Restrict Access on Particular Systems

You can prevent all Strobe activity (other than the ability of users to measure their own jobs) on specific systems with a RACF profile. With Strobe Release 17.02 and more current, the FACILITY class default can be user-defined, as described by the PARMLIB parameter SECURITY_CLASS=.

RDEFINE FACILITY $STROBE.sysname.* UACC(NONE)

You can also restrict certain users or groups of users from specific systems.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*