Closed liga-oz closed 5 months ago
Nice!
I'm happy with the changes but I have one more thought: We could have also moved the new logic into the ClientCertificate class which has one constructor for String-based certificate+key and one constructor for a PrivateKey/Certificate[] combination. Internally, the class could compute the missing parameters from the provided ones, such that the getters are all non-null, no matter what the instance was constructed from. In the SSLContextFactory, one could then always call getPrivateKey and getCertificateChain without having to differentiate between the formats. Not sure which alternative is better but in the second option, I think it is nicer that the support of different certificate formats/classes would be isolated in the ClientCertificate class and not spread across modules.
the idea is quite good, but that would be quite a big chunk of logic that goes into certificate class and it would be a bit bigger refactoring and I would say too big for this PR. I'll create a BLI for this as it's not that high Prio but good to have thing 👍🏻
Sample App for testing ZTIS with XSUAA https://github.com/SAP/cloud-security-services-integration-library/tree/zero_trust_sample_app_xsuaa/samples/spring-security-hybrid-usage