TCK Challenge: openid default test needs to use signed JWT token

[brideck]

Challenged Tests:
ee.jakarta.tck.security.test.OpenIdDefaultIT#testOpenIdConnect
ee.jakarta.tck.security.test.OpenIdWithELIT#testOpenIdConnect

TCK Version:
Jakarta Security TCK 3.0.0

Tested Implementation:
Open Liberty

Description:
Section 2 of the OpenID Connect specification states "ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively..." The TCK's OpenID configuration is written to use a token signing algorithm of "RS256," which would be sufficient to meet this requirement, and the @OpenIdAuthenticationMechanismDefinition for the tests is also using the default value for idTokenSigningAlgorithmsSupported of "RS256."

However, the OIDC provider implementation in the test is merely using PlainJWT, an unsigned token. This is both contrary to the test's configuration and the needs of the OIDC spec itself. Accordingly, Open Liberty rejects this token and does not allow authentication to occur.

The TCK needs to be updated to use a signed token (perhaps SignedJWT?) in order to test this function correctly.

[brideck]

Open Liberty security developers are taking a look at this to see what a full potential solution might look like, but we do not have one yet. We would, of course, be open to ideas and solutions from elsewhere in the community as well.

[jimmy1wu]

i have created a potential solution, which works with openliberty, in: #278

let me know what you think 😄

[teddyjtorres]

Hi @arjantijms,
Please let us know if this challenge can be accepted and if #278 would be a viable solution.

Regards,
Teddy

[arjantijms]

Please let us know if this challenge can be accepted and if #278 would be a viable solution.

#278 looked good indeed. I've merged it and will conclude the challenge. Should there be anything else the issue can be re-opened.

[brideck]

@arjantijms Ach. I don't think the work on this test is done yet. Did some integration testing of all these challenge-related PRs and the app-openid tests are still failing for us in Open Liberty due to the sort of issue #273 was opened for.

Part of the needed solution would be to update https://github.com/arjantijms/security/blob/master/tck/app-openid/src/main/resources/openid-configuration.json to use HTTPS endpoints, but after that it looks like there's still some sort of certificate configuration needed to make it work. We're trying to figure it out on our end, but wanted to give you a heads up.

[teddyjtorres]

Reopened since the solution is incomplete.

[brideck]

We're dancing around locking in a solution for this, but are trying to find a good way to automate things a little better. It involves a) the aforementioned update to openid-configuration.json and b) passing the server's credentials into the test client via javax.net.ssl properties on the maven-failsafe-plugin.

We're also trying to not need a hardcoded URL at https://github.com/jakartaee/security/blob/master/tck/app-openid/src/main/java/ee/jakarta/tck/security/test/server/OidcProvider.java#L184

[teddyjtorres]

PR #285 addresses updating the provider to use https endpoints and how to configure for server trust.

[arjantijms]

PR #285 addresses updating the provider to use https endpoints and how to configure for server trust.

Thanks! The surrogate demo app was indeed expected to need some additional configuration options as more servers started to use it, and more requirements emerged.

[teddyjtorres]

@arjantijms Thank you for approving #285. Please let us know if 3.0.1-TCK could be staged for release. Thanks!