Skip to main content
Version: v2.7.x LTS

SAF Resource Checking Providers

SAF Resource Checking Providers

Verification of the SAF resource is provided by the following three providers described below.

REST endpoint call#

The REST provider calls the external API to retrieve information about access rights. To enable the feature outside of the mainframe, such as when running in Docker, you can use a REST endpoint call using the GET method:

  • Method: GET
  • URL: {base path}/{userId}/{class}/{entity}/{level}
  • Response:
    {        "authorized": "{true|false}",        "error": "{true|false}",        "message": "{message}"    }

Note: For more information about this REST endpoint call, see ZSS implementation.

Native#

The Native provider is the easiest approach to use the SAF resource checking feature on the mainframe.

Enable this provider when classes com.ibm.os390.security.PlatformAccessControl and com.ibm.os390.security.PlatformReturned are available on the classpath. This approach uses the following method described in the IBM documentation: method.

Note: Ensure that the version of Java on your system has the same version of classes and method signatures.

Dummy implementation#

The Dummy provider is for testing purpose outside of the mainframe.

Create the file saf.yml and locate it in the folder, where is application running or create file mock-saf.yml in the test module (root folder). The highest priority is to read the file outside of the JAR. A file (inner or outside) has to exist.

The following YAML presents the structure of the file:

  safAccess:    {CLASS}:      {RESOURCE}:        - {UserID}

Notes:

  • Classes and resources are mapped into a map, user IDs into a list.
  • The load method does not support formatting with dots, such as shown in the following example: Example: {CLASS}.{RESOURCE} Ensure that each element is separated.
  • The field safAccess is not required to define an empty file without a definition.
  • Classes and resources cannot be defined without the user ID list.
  • When a user has multiple definitions of the same class and resource, only the most privileged access level loads.