Only the z/OS security administrator, for example, the SPECIAL user for RACF, can submit and fix eventually.
This great capability is also available for programming interface. It would be helpful to provision required security when deploying dev-ops environments.
This new REST service allows you to focus on security requirements that could be organized by product or function, instead of the need to understand complex command syntax and differences among various security products.
The security requirements can be specified directly in the HTTP request body or in a separate USS file. For either way, the format of requirements is in JSON which is easy to understand and code. Here is an example
{
"resourceItems": [
{
"resourceProfile": "IZUDFLT.ZOSMF.CONFIGURATION.SECURITY_ASSISTANT",
"resourceClass": "ZMFAPLA",
"access": "READ"
}
]
}
If the security requirements are described in the HTTP request body, post request should be sent to z/OSMF in below format
POST /zosmf/config/security/v1/provision?userid=<userid>
If the security requirements are described in a standalone USS file, post request will be like
POST /zosmf/config/security/v1/provision/descriptor?userid=<user-id>
And the HTTP request body should be replaced with the path of that USS file, for example:
{
"path": "/tmp/example.json"
}
The SCA Provisioning REST APIs accept the above security requirements and then automatically validates if the target user or group (specified by <userid>) has access to the specified security requirements. If not, the API provision required security for you automatically and then returns results in HTTP response body like below:
{
"resourceItems": [
{
"resourceProfile": "IZUDFLT.ZOSMF.CONFIGURATION.SECURITY_ASSISTANT",
"resourceClass": "ZMFAPLA",
"access": "READ",
"actionObjectId": "zosmft1",
"status": "passed",
"action": "provision",
"validatedId": "zosmft1"
}
]
}
"provision" status means the described security requirement has been provisioned by this API calling.
Disclaimer: This document intends to represent the views of the author rather than IBM. Please contact the author lilzhi@cn.ibm.com instead of IBM service for any questions.