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
zosConnect-2.0 Applies to zosConnect-2.0.
- You must be familiar with the information in Generating a JWT within IBM z/OS Connect.
- Set up the connection from the z/OS subsystem
to the z/OS Connect Server.
- For CICS, see Configure CICS to access z/OS Connect to call APIs.
- For IMS, see Configuring IMS to access z/OS Connect for API calls.
- For other z/OS applications, see Configuring other z/OS applications to access z/OS Connect Server for API calls.
- Complete the task How to activate and configure the SAF user registry to configure the 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 z/OS Connect Server instance must have READ access to the BPX.SERVER FACILITY class profile.
- If you are running with z/OS 3.1 or earlier,
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 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 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 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 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
jwtBuilderandzosconnect_authTokenLocalelements to define the parameters that are used to generate a JWT locally. The parameters include the claims that are registered in the IANAJSON 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 IANAJSON Web Token Claims
registry, see JSON Web Token Claims Registry. - Reference the
zosconnnect_authTokenLocalelement from thezosconnect_endpointConnectionelement.
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.