Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #4128 - test the decoding of OpenId Credentials #4166

Merged
merged 11 commits into from Nov 20, 2019

Conversation

lachlan-roberts
Copy link
Contributor

new tests for changes from PR #4129 for issue #4128

Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
…128-testDecoderPadding

Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
joakime
joakime previously requested changes Oct 9, 2019
Copy link
Contributor

@joakime joakime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs real world encoded examples that MUST decode AND require the strange padding hack.

@travisspencer
Copy link
Contributor

@joakime , it would be great if Java provided a decoder/encoder that worked with JOSE, but, to the best of my knowledge, it doesn't. That knowledge has been gained by built an entire OpenID Connect server in Java writing similar Java modules to this for use in Web apps and APIs.

The "real-world" examples may not exist in the test, but what @lachlan-roberts has added are the quintessentials plus some more exotic corner cases that we should not expect to receive but can now handle in case we do. The reason for this is that the decoding is done on parts of the JWT. a JWS (a signed JWT) is made up of 3 parts separated by a dot. This special decoding has to be done on each of these 3 parts. The "hacky" padJWTSection method (which is similar to the example in the JOSE RFC, so not sure how "hacky" it is BTW), is just to decode each of these parts of the JWS. For this reason, the real world input would need to execute more than just the code that's currently under test.

Hope this clarifies and relieves any anxiety you might have about this test or this new code.

@joakime
Copy link
Contributor

joakime commented Nov 5, 2019

I have nothing to add to this PR.
At this point I'm neutral on it.
My only concerns were with the Base64 behaviors, not the OpenID behaviors.
I'm withdrawing review request entirely.

@joakime joakime requested review from joakime and removed request for joakime November 5, 2019 22:32
@joakime joakime dismissed their stale review November 5, 2019 22:32

I'm neutral.

@joakime joakime removed their request for review November 5, 2019 22:32
…128-testDecoderPadding

Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
@lachlan-roberts
Copy link
Contributor Author

@travisspencer could we use your example from #4128 in a test as a real world example which demonstrates this issue?

Object parsedJwtHeader = JSON.parse(jwtHeaderString);
if (!(parsedJwtHeader instanceof Map))
throw new IllegalStateException("Invalid JWT header");
Map<String, Object> jwtHeader = (Map)parsedJwtHeader;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the safest of casts. I'd check that the keys are strings using code like we've done in previous PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a Map with keys that are not strings even be valid JSON. If our JSON parser is capable of returning invalid JSON then we should fix that in the parser rather than testing the return type is valid everywhere it is used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point, and do not oppose this change given that argument. However, I still would do the conversion at run-time to a Map<String, Object> and not cast it to that. We're not in a high throughput case here. We can tolerate 250ms for the entire code flow + login (say 6 request/responses) in most cases I've seen. So, I'd err on the side of clean code that relies on the compiler for type checking. As I said though, your argument is hard to dispute.

Object parsedClaims = JSON.parse(jwtClaimString);
if (!(parsedClaims instanceof Map))
throw new IllegalStateException("Could not decode JSON for JWT claims.");
return (Map)parsedClaims;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method returns a typed map. These types should be checked as well before returning.

@travisspencer
Copy link
Contributor

Yes, @lachlan-roberts . That JWT should work. You can decode it using oauth.tools, BTW. There, you can see that the purpose claim is id, so it's an ID token like the one that an OP will issue to Jetty.

Copy link
Contributor

@janbartel janbartel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, this looks good to me - seems like it's mostly a refactor of existing code. But, not being an expert in the JWT area, I'm leaving critique of the substance of this code in the very capable hands of @travisspencer . My comments are purely in the syntactic/coding practice area. I also note @joakime's suggestion to have some positive tests, and that would be good, if at all possible.

Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
@travisspencer
Copy link
Contributor

@janbartel , I've looked again. The handling of the JWTs seems good to me.

@lachlan-roberts
Copy link
Contributor Author

Thanks @travisspencer!
I have also added the test with the JWT example from #4128 in commit 67ec3d2.
I will go ahead and merge.

@lachlan-roberts lachlan-roberts merged commit cff6bb4 into jetty-9.4.x Nov 20, 2019
@lachlan-roberts lachlan-roberts deleted the jetty-9.4.x-4128-testDecoderPadding branch November 20, 2019 03:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants