In z/OS, it is standard practice to control access to various resources—everything from data sets to interaction with specific APIs. One of the most common ways to achieve controlled access is by leveraging security profiles provided by Resource Access Control Facility (RACF). More specifically, clients can define a security profile for a particular resource and only user IDs that have access to that profile are permitted to interact with that resource. The latest delivery of Machine Learning for IBM z/OS (MLz) via APAR PH69959 introduces a new authorization scheme that brings these profile capabilities to life.

• System Administrator (sysadm): Full‑privilege role responsible for configuring, managing, and administering MLz.
• Machine Learning Administrator (mladm): Manages all models and deployments within MLz.
• Model Developer (devuser): Creates, updates, and manages their own models within MLz.
• Application Developer (appuser): Has permissions to invoke scoring (inference) requests on all deployment models.
• API User (apiuser): Restricted role that allows interaction only with the user's own models and deployments.

Access to each role is guarded by a corresponding XFACILIT class profile, sharing the same name as the MLz roles:

• ALN.ROLE.<MLz instance name>.DEVUSER
• ALN.ROLE.<MLz instance name>.MLADM 
• ALN.ROLE.<MLz instance name>.SYSADM
• ALN.ROLE.<MLz instance name>.APPUSER
• ALN.ROLE.<MLz instance name>.APIUSER

One thing that may stand out in the profiles above is the MLz instance name, another new thing introduce with this APAR. Now, each MLz instance must have a name that is 1—15 characters long, and consists of uppercase letters (A—Z) and numbers (0—9).  With instance names, a system administrator can isolate or unify access to various instances as needed. In the case of a cluster, it's advisable to use the same MLz instance name for all the MLz instances.

Now back to our scheduled program...

With the new XFACILIT class profile authorization scheme, it's easy to grant and edit access for users. For instance, to grant user ID, MLZUSE1, access to the various actions that correspond to the APIUSER role, all you need to do is:

1. Define the profile

RDEFINE XFACILIT ALN.ROLE.<MLz instance name>.APIUSER

2. Grant MLZUSE1 READ access to the profile

PERMIT ALN.ROLE.<MLz instance name>.APIUSER CLASS(XFACILIT) ACCESS(READ) ID(MLZUSE1)

3. Don’t forget the refresh!

SETROPTS RACLIST(XFACILIT) REFRESH

And you’re all set!

If the user associated with MLZUSE1 switches to a different department, all you need to do is change their access to NONE, followed by a RACLIST REFRESH.

Alternatively and for ease of maintenance, a security administrator can grant a RACF group access to an MLz XFACILIT class profile, instead of granting access to individual user IDs one at a time.

From an MLz API interaction perspective, all interactions with the MLz REST APIs (model import, deploy, scoring server, etc) continue to require a valid JWT (JSON Web Token). The change is in the code that's invoked when the JWT is first obtained: the roles represented in the generated JWT will reflect which MLz XFACILIT class profiles the user ID is authorized for.

In addition, to cover the case where a user’s privilege have been augmented in the time between the initial creation of the JWT and its subsequent use, the roles in the JWT will be revalidated during each REST API interaction with the MLz Core Server. In contrast, REST API interactions with the MLz Scoring Server will continue to ensure token validation only, without role revalidation.

Another really notable security feature available with z/OS is z/OS DFSMSdfp Cloud Data Access (CDA). The service is designed to communicate with Cloud Object Storage and includes a credential store that can be leveraged as a standalone entity.  And that's exactly what MLz is now doing for credentials associated with Db2® for z/OS used by the repository service and zCX and Linux® on Z hosts used by the ONNX Compiler and Trustworthy AI (zCX only) services. 

The configuration of CDA cloud credential storage is specialized for MLz's utilization. The GDK <userid> is the <mlz_setup_userid> that the MLz server is associated with, the <provider> is ALN, the MLz designated prefix, and the ~/gdk needs to resides in the <mlz_setup_userid> home directory.

The following table shows the parameters used to define MLz user-provided credentials in CDA cloud credential storage:

And finally, the latest delivery introduces support for secure Db2® connections where Db2® for z/OS is used by the repository services.  Configuration of this feature requires a secure Db2® port, a Db2® certificate, and updates to the JDBC properties. A user ID with SYSADM role privileges can enable this in the UI or via the command line by running the aln-sysconfig.sh utility. 

To find out more about MLz, visit one of the following links: 

• https://www.ibm.com/support/z-content-solutions/machine-learning-zos/
• https://www.redbooks.ibm.com/abstracts/sg248552.html
• https://www.ibm.com/docs/en/wml-for-zos/enterprise/3.2.0