feat: apiml Spring-Modulith based module with ZAAS service

[taban03]

Description

Include ZAAS service as part of Spring Modulith API ML module.

Linked to # (issue)
Part of the # (epic)

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

[pj892031]

Can we replace this with a human-readable message? Actually, the exception is never thrown. It is maybe a question of whether we need it. Maybe calling a method that just generates a message is enough.

[pablocarle]

@achmelo is on this one I think

[pj892031]

If this is not true (ie. x509), what is the response? 404 because of Mono.empty? Do we really need to define the type of authentication? Method `getPrincipal is everywhere, so I consider it redundant.

[pablocarle]

This comes from the original implementation in zaas-service's SuccessfulTicketHandler
I believe the /ticket endpoint doesn't have user mapping x509 authentication supported, it only has certificate like /eureka/** endpoints do

[pablocarle]

If we want to add suppot for the additional method we should probably create a feature

[pj892031]

Since we are in the WebFlux we should mainly focus on SslInfo and replace it like here:

api-layer/gateway-service/src/main/java/org/zowe/apiml/gateway/attls/AttlsHttpHandler.java

Lines 105 to 106 in 2ce6e5b

	var sslInfo = AttlsSslInfo.builder().peerCertificates(certs).build();
	return request.mutate().sslInfo(sslInfo).build();

The attributes look more-less like back-compatibility with Servlets, but do not forget these attributes are not the same as on the request level (see https://github.com/zowe/api-layer/blob/2ce6e5bb44f5862a1fe91a6a4cd8398aff6f7a08/gateway-service/src/main/java/org/zowe/apiml/gateway/filters/RequestAttributesProvider.java).

I am not sure if this is the best way to handle client certificates now. Maybe we should think about a custom implementation of SslInfo.

[pablocarle]

Out of ignorance here, you are claiming they are not the same, however by tests it seems they are set. Can you explain the differences? What are the pitfalls of the current implementation?

[sonarqubecloud]

Quality Gate passed

Issues
21 New issues
0 Accepted issues

Measures
0 Security Hotspots
81.3% Coverage on New Code
0.6% Duplication on New Code

See analysis details on SonarQube Cloud