Skip to content

Service-Initiated Pass-ticket Generation for AI Agent Scenarios #4365

@havenkat

Description

@havenkat

Is your feature request related to a problem? Please describe.

The existing pass-ticket generation system is designed for active/logged-in users (where the user directly authenticates and requests their own pass-ticket). However, a new requirement exists for AI Agent scenarios where a Service needs to programmatically request a pass-ticket on behalf of a specified user to facilitate subsequent service access.

Describe the solution you'd like

Delegation of Trust and Service-to-User Impersonation : We need to modify or introduce a new mechanism to allow an authenticated Service to request a pass-ticket for an arbitrary user, using the combination of the target user's emailId and the applId (application identifier).

Service Authentication (New Prerequisite): The requesting Service itself must first be securely authenticated. This will be achieved using Zowe to obtain a Bearer token for the Service, which proves its identity and authorization to request pass-tickets.

Pass-ticket Generation (Core Change): The generation API must accept:

  • The Service's Bearer Token (from Zowe) for authentication.
  • The target user's emailId.
  • The target applId.

Usage: The resulting pass-ticket must be returned to the Service, which will then use it as a Bearer token in the Authorization header when making requests on behalf of the target user to the downstream services (e.g., within the AI Agent workflow)

Describe alternatives you've considered
None

Willingness to help
Yes, PR will be raised

Additional context
To establish a secure, controlled, and auditable process where an authenticated Service (via a Zowe-issued Bearer token) can request and obtain a unique, user-specific pass-ticket (based on emailId and applId). This enables the Service to securely delegate its identity and act as the specified user for interacting with target systems within AI Agent workflows, while using the generated pass-ticket as the necessary Bearer token for user-context authorization

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestnewNew issue that has not been worked on yet

    Type

    No type

    Projects

    Status

    New

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions