feat: API for delegating credentials to generate a z/OS PassTicket

[Goutham024]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Linked to #4365
Part of the # (epic)

Type of change

Please delete options that are not relevant.

• fix: Bug fix (non-breaking change which fixes an issue)
• feat: New feature (non-breaking change which adds functionality)
• docs: Change in a documentation
• refactor: Refactor the code
• chore: Chore, repository cleanup, updates the dependencies.
• BREAKING CHANGE or !: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the style guidelines of this project
• PR title conforms to commit message guideline ## Commit Message Structure Guideline
• I have commented my code, particularly in hard-to-understand areas. In JS I did provide JSDoc
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The java tests in the area I was working on leverage @nested annotations
• Any dependent changes have been merged and published in downstream modules

For more details about how should the code look like read the Contributing guideline

[Goutham024]

OLD PR: #4364
In the above PR I encountered multiple merge conflicts while rebasing for the DCO fix, as the branch was behind 155 commits with v3.x.x. After trying to sync with the latest changes, the conflicts became quite extensive and time-consuming to resolve. To simplify the process, I’ve created a this PR instead. Please review the PR.

[havenkat]

@balhar-jakub @pablocarle there was some issue with the previous pr for signing, hence created this new one. we will discuss in this pr.
CC: @Joe-Winchester

[havenkat]

@pablocarle @balhar-jakub PR is ready for review

[balhar-jakub]

We believe that this is the actual PR to solve the passtickets endpoint.
As such we close #4364
If this is not the correct one, let us know.

[havenkat]

We believe that this is the actual PR to solve the passtickets endpoint. As such we close #4364 If this is not the correct one, let us know.

Yes, this is the active PR.

[Joe-Winchester]

I recall that guarding the API we were going to check that the user associated with the client certificate was going to be checked against a SAF permission to make sure they had CONTROL access to a SAF FACILITY class APIML.DELEGATED.PASSTICKET.

@pablocarle , do you have pointers to sample existing code in APIML that makes a call to do a SAF access permission check against a facility class ?

[pablocarle]

I recall that guarding the API we were going to check that the user associated with the client certificate was going to be checked against a SAF permission to make sure they had CONTROL access to a SAF FACILITY class APIML.DELEGATED.PASSTICKET.

@pablocarle , do you have pointers to sample existing code in APIML that makes a call to do a SAF access permission check against a facility class ?

Hi @Joe-Winchester, sure, if you have a controller you can use the example from the documentation:

https://github.com/zowe/api-layer/blob/v3.x.x/docs/saf-authorized-endpoints.md#protecting-access-to-rest-api-endpoints

This can also be used as an injected bean, like here:
https://github.com/zowe/api-layer/blob/v3.x.x/apiml/src/main/java/org/zowe/apiml/controller/ReactiveSafResourceAccessController.java#L44