How to configure a locally generated JWT
To call an API with a locally generated JWT, you must configure the
jwtBuilder
and zosconnect_authTokenLocal
elements in the
server.xml configuration file and define SAF SURROGAT profiles.
Before you begin
- You must be familiar with the information in Calling an API secured with a locally generated JWT.
- Set up the connection from the z/OS subsystem
to the IBM z/OS Connect server.
- For CICS, see Configure CICS to access IBM z/OS Connect to call APIs.
- For IMS, see Configuring IMS to access IBM z/OS Connect for API calls.
- For other z/OS applications, see Configuring other z/OS applications to access IBM z/OS Connect for API calls.
- Complete the task How to activate and configure the SAF user registry to configure the IBM z/OS Connect server to use z/OS authorized services and a System Authorization Facility (SAF) user registry.
- For the surrogate check on the z/OS application asserted user ID,
you must ensure that the following requirements are completed:
- The user ID that is used to run the IBM z/OS Connect server instance must have READ access to the BPX.SERVER FACILITY class profile.
- The Java™ library libifaedjreg64.so
must be program-controlled. For example, enter the following command:
extattr +p /usr/lib/java_runtime/libifaedjreg64.so
- Third-party native code or native libraries, such as those used by a IBM z/OS Connect interceptor must be program-controlled.
To define the native code or native library to be program-controlled, enter the following command
under z/OS
UNIX System Services:
extattr +p <your library file path>Note: When your administrator applies maintenance to the Java library, this setting might be reset, so you must reenter this command.
About this task
You configure the IBM z/OS Connect server to
generate a JWT with the "sub"
(Subject) claim set to the z/OS application asserted user ID, and send that JWT in the
specified HTTP header on the request to the RESTful API.
The z/OS application asserted user ID needs to be defined in the SAF security manager on the LPAR where IBM z/OS Connect is running.
The authenticated link user ID must be a SAF user ID. Therefore, if authenticating with a TLS client certificate, the certificate must be mapped to a SAF user ID. If using a distributed identity to authenticate with basic authentication, then that distributed identity must be mapped to a SAF user ID. The link user ID requires surrogate access to generate a JWT on behalf of the z/OS application asserted user ID. This is achieved by using SAF SURROGAT class profiles. If there is no authenticated link user ID associated with the API requester request, then the check is performed against the SAF unauthenticated user ID. See SAF unauthenticated user ID.
The authenticated link user ID requires authorization to connect to the IBM z/OS Connect server. Either the authenticated link user ID, or the z/OS application asserted user ID, requires authorization to the API requester, depending on whether identity assertion is configured. For more information about authorization, see API requester authorization.
This task assumes that RACF is used as security manager. If you are using an alternative SAF security manager, refer to the appropriate product documentation for the equivalent commands.
- Configure the
jwtBuilder
andzosconnect_authTokenLocal
elements to define the parameters that are used to generate a JWT locally. The parameters include the claims that are registered in the IANA "JSON Web Token Claims" registry (for example, the"aud"
(Audience) claim), public and private claims, and additional attributes of a JWT. For more information about the IANA "JSON Web Token Claims" registry, see JSON Web Token Claims Registry. - Reference the
zosconnnect_authTokenLocal
element from thezosconnect_endpointConnection
element.
Procedure
Results
jwtBuilder
and
zosconnect_authTokenLocal
elements. The generated JWT payload contains the
specified claim names and values, and the "sub"
(Subject) claim of the JWT is set
to the z/OS application asserted user ID. The JWT is sent on
the API request to the RESTful API in the specified HTTP header (by default the Authorization
header). The HTTP header includes the "Bearer" scheme keyword followed by the JWT.