Distributed (OIDC) Authentication Scheme

[balhar-jakub]

Use Cases

• There is a client application on the distributed side that needs to communicate with the services running on the zOS. The client needs to access the zOS services under its own authority. For some reason, the client application can't use a client certificate to authenticate with API ML ZAAS service. Similarly, Personal Access Token is not an option. A possible solution is that the client properly implements OIDC protocol and uses OAuth2 Client Credentials flow to authenticate with the distributed IdP/IAM. The outcome of the client's successful authentication is an OAuth2 access token which can be used to communicate via Gateway towards the zOS services.

• There is a client application on the distributed side that needs to access zOS resources on behalf of a user working with the client application using some kind of user interface (User Agent). The client application properly implements OIDC protocol and allows the user to authenticate with a distributed IdP/IAM. The outcome of successful user authentication and client application authorization by the user is a set of tokens: Access Token, ID token, and optionally Refresh Token. The client application can use the ID token for user profile information and the Access Token for access to zOS resources through API ML GW.

For the above use cases to work, API ML must implement OIDC authentication scheme and be able to translate/propagate distributed identities encoded in the access token to mainframe identities.

Acceptance Criteria

• There is a new authentication scheme - oidc
  • The oidc scheme is supported on the northbound
  • The identity from the oidc/oauth token is translated/propagated to a mainframe identity encoded in a Zowe Token (z/OSMF, SAF IDT) which is supported on the southbound
• The usage is demonstrated with OKTA as distributed IdP.
• The scheme is properly documented in the Zowe Docs. The documentation belongs to the Extend section.