Multi-tenancy APIML deployments

[pinpan]

Some applications may need to access data from different zOS systems (tenants, domains). Working with multiple API ML systems dedicated to the respective domain brings in a high level of complexity for the client and needs to be

Product requirements:

• Client applications in multitenancy mode access APIs from multiple, potentially disconnected zOS systems.
• The clients need support for Single Sign On across a number of security domains where the client application users have potentially different identities.

Technical Requirements:

• The client applications communicate with APIs from different tenants through a central API ML gateway.
• The client applications work with a single (non-mainframe) user identity managed by distributed IAM system.
• The central API GW provides security services at minimum access token validation.
• The central API GW is deployed as multiple clustered instances.
• The client application route the requests to the domain (tenant) specific API ML dedicated to the corresponding zOS system.

Design:

• A central proxying API ML exists, which knows all the API services' end-points available on any of the API ML systems.
• The central API services catalog is actively synchronized off-band to not interfere with normal API traffic which may degrade the system availability and performance.
• The proxy API ML GW implements routing rules to properly address the services based at the minimum on the:
  • Tenant ID
  • SYSPLEX ID
  • Environment ID
  • Service ID.
  • The proxy API ML provides authentication and limited authorization services to the client.

[pinpan]

Additional considerations
configuration:

• Central API ML initial configuration
• Security domains - topology, updates
• Services registration - push, pull
• Heartbeats, Health checks
• Monitoring
• Logging
• Certificates

[balhar-jakub]

Implemented and documented by Zowe 2.13