feat: Passticket delegations

[Goutham024]

Description

Linked to #4365

Type of change

• feat: New feature (non-breaking change which adds functionality)

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

[havenkat]

This is corresponding to the issue : #4365

[pablocarle]

Hi, we currently have a gateway/api/v1/auth/ticket endpoint that can create a passticket for a given user, I believe it is protected by client certificate authentication (i.e. service to service)
Could this be an enhancement on that existing endpoint? Am I missing something?

[pablocarle]

Also, please make sure you commit signed-off commits only, you can find a git command to fix the current ones if you click on the DCO item from the workflow list

[balhar-jakub]

Would you be able to join us on the API ML Squad call to discuss the integration and the implementation?

[havenkat]

@pablocarle @balhar-jakub appreciate your help and review.

• I had reviewed /auth/ticket api, and understood that it is generating the passticket for the currently logged-in user, that is user in the jwt token.

My requirement is : service generates a passticket for a user, and we have only emailid of that user at this time.

Yes, I would like to join the call, also @Joe-Winchester is part of that call to discuss the same.

[pablocarle]

@pablocarle @balhar-jakub appreciate your help and review.

* I had reviewed /auth/ticket api, and understood that it is generating the passticket for the currently logged-in user, that is user in the jwt token.

My requirement is : service generates a passticket for a user, and we have only emailid of that user at this time.

Yes, I would like to join the call, also @Joe-Winchester is part of that call to discuss the same.

Got it, yes, and the lack of user credentials to create a PassTicket for a user is a conflicting topic, it probably can't go out without restrictions as it opens the door to create any PassTicket for any user and ApplId without properly verifying credentials.
We can have a discussion in the Squad call, would you be able to join next one next Wednesday?

[Goutham024]

@pablocarle @balhar-jakub 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 new PR instead. Please review the PR linked below going forward.

#4368

[Joe-Winchester]

@pablocarle

Got it, yes, and the lack of user credentials to create a PassTicket for a user is a conflicting topic, it probably can't go out without restrictions as it opens the door to create any PassTicket for any user and ApplId without properly verifying credentials. We can have a discussion in the Squad call, would you be able to join next one next Wednesday?

Apologies we couldn't join the last couple of APIML squad call, but we defo want to discuss.

For the API the use case is that an external agent can create passtickets for arbitrary e-mails (that are RACMAPed). The userID that can do this is protected by needing UPDATE permission to IRRPTAUTH..* in class PTKTDATA, so it's already guarded.
For example, if a user IBMUSER (even if it has SPECIAL-OPERATIONS) tries to generate a passticket it must have been defined with

PERMIT IRRPTAUTH.IZUDFLT.* CLASS(PTKTDATA) ID(IBMUSER) ACCESS(UPDATE)

Any other user who tries to use the API will get a 400 or 500 response.
For the client agent who is using this, our thought process was to create an x509 cert for the specific user and put that into the keystore of the client machine, so mtls does the authentication.