z/OSMF Mock Service does not correctly mock z/OSMF authentication API

[JirkaAichler]

Describe the bug z/OSMF authentication API is incorrectly mocked which makes the service unreliable. It is difficult to write reliable integration tests. APARs are also not well documented.

• Mocked /info endpoint always returns only ltpa token. z/OSMF can also return JWT when configured to do so.
• Mocked /authenticate endpoint does not accept JWT in the cookie. The current z/OSMF can accept it.
• With multiple mock Apars configured, multiple tokens (jwt and ltpa) are returned. 2 Apars = 2 jwt + 2 ltpa in response.

Other behavior also does not correspond to the real z/OSMF implementation that we are running. The mock should be reviewed.

Expected behavior Quick solution: Review the mock if it is accurate and make the changes. Preferred solution: Drop support of the legacy z/OSMF versions and set the required z/OSMF maintenance level as the prerequisite. Support only 2 modes: ltpa and jwt. Update the mock that will be significantly simplified. I would recommend dropping the mock service completely and replacing it with a wire mock or something similar.

[balhar-jakub]

As for the preferred solution it's not going to happen for V2 and for V3 we already have presented this limitation on z/OSMF supported versions. Is there anything missing?

[JirkaAichler]

It is not considered a breaking change to drop support of unsupported prerequisites. For example, dropping support of not supported z/OS versions. z/OSMF is the same case. But if we want invest to in maintaining a mock of unsupported stuff ...

[balhar-jakub]

Interesting that this isn't considered breaking change as such we should be able to just at any point move to Spring Cloud Gateway as Netlfix Zuul isn't supported technology anymore anyway.

How do we distinguish between what is breaking in this case?

[JirkaAichler]

I agree that replacing Zuul is not a breaking change if no feature (including the configuration) is affected. I don't know if this is achievable.

I made the previous comment based on my previous experience with several mainframe products.

I tried to google the policy that describes what is the breaking change not just in the mainframe world. For example, the following document says: https://opensource.google/documentation/policies/library-breaking-change

dropping support for a platform that itself is outside of vendor support may not be considered a breaking change.

[balhar-jakub]

@JirkaAichler This feels like a TSC-level discussion. I am a big fan of dropping support for unsupported versions. I am just careful around breaking changes as there was already some amount of confusion about them.

[balhar-jakub]

Just a note: the V3 will require z/OS 2.5 due to the Java 17 requirement and as such, only z/OSMF with V2R5 and above will be supported.

[balhar-jakub]

As of the decision of the TSC, we are ok with dropping support for unsupported versions of dependencies. The support policy will explain that and will be approved by TSC.