8000 Implement DPoP for all grantTypes by Captain-P-Goldfish · Pull Request #29967 · keycloak/keycloak · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Implement DPoP for all grantTypes #29967

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

Merged
merged 4 commits into from
Jul 29, 2024
Merged

Conversation

Captain-P-Goldfish
Copy link
Contributor
@Captain-P-Goldfish Captain-P-Goldfish commented May 29, 2024

Fix claiming userInfoToken with DPoP

  • tokenType must be DPoP as defined in RFC9449 chapter 7.1

closes #30181
closes #30179

relatesTo #22311

Copy link
@keycloak-github-bot keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

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

Unreported flaky test detected, please review

@keycloak-github-bot
Copy link

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.broker.KcOidcBrokerTest#testPostBrokerLoginFlowWithOTP_bruteForceEnabled

Keycloak CI - Java Distribution IT (windows-latest - temurin - 19)

java.lang.AssertionError: expected:<Invalid authenticator code.> but was:<null>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:120)
	at org.junit.Assert.assertEquals(Assert.java:146)
...

Report flaky test

@mposolda
Copy link
Contributor

@tnorimat Could you please help me review this one if you have some free cycles?

@keycloak-github-bot
Copy link

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.broker.KcOidcBrokerTest#testPostBrokerLoginFlowWithOTP_bruteForceEnabled

Keycloak CI - Java Distribution IT (windows-latest - temurin - 19)

java.lang.AssertionError: expected:<Invalid authenticator code.> but was:<null>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:120)
	at org.junit.Assert.assertEquals(Assert.java:146)
...

Report flaky test

Copy link
@keycloak-github-bot keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

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

Unreported flaky test detected, please review

@tnorimat
Copy link
Contributor

@mposolda Hello, Yes I will review the PR.

Copy link
Contributor
@tnorimat tnorimat left a comment

Choose a reason for hiding this comment

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

@Captain-P-Goldfish Hello, I add one minor review comment. Could you check it?

try (CloseableHttpClient client = HttpClientBuilder.create().build()) {
HttpGet get = new HttpGet(getUserInfoUrl());
get.setHeader("Authorization", "Bearer " + accessToken);
get.setHeader("Authorization", accessTokenResponse.getTokenType() + " " + accessTokenResponse.getAccessToken());
if (dpopProof != null) {
get.addHeader("DPoP", dpopProof);
Copy link
Contributor

Choose a reason for hiding this comment

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

"DPoP" might be TokenUtil.TOKEN_TYPE_DPOP.

Copy link
Contributor Author
@Captain-P-Goldfish Captain-P-Goldfish May 31, 2024

Choose a reason for hiding this comment

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

I am not sure where you are getting at?
Do you want the code like this?

get.setHeader("Authorization", TokenUtil.TOKEN_TYPE_DPOP + " " + accessTokenResponse.getAccessToken());

I don't think that this is a good idea. There is at least one case in which token_type Bearer is returned:

  • DPoP not required
  • DPoP not sent in AuthorizationRequest

You also added such a test and this test would fail then.

Copy link
Contributor

Choose a reason for hiding this comment

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

L1183 get.addHeader("DPoP", dpopProof);
to
get.addHeader(TokenUtil.TOKEN_TYPE_DPOP, dpopProof);
But, you need not to modify it.

@Captain-P-Goldfish
Copy link
Contributor Author
Captain-P-Goldfish commented May 31, 2024

It would also be good to restructure the implementation here.
Currently DPoP is not supported for other grantTypes than AuthorizationCode. We should think of a way to add it dynamically to all grantTypes even customized grantTypes. But this would be a different ticket :-)

EDIT:
I created a task for this
#30179

@mposolda
Copy link
Contributor
mposolda commented Jun 5, 2024

It would also be good to restructure the implementation here. Currently DPoP is not supported for other grantTypes than AuthorizationCode. We should think of a way to add it dynamically to all grantTypes even customized grantTypes. But this would be a different ticket :-)

@Captain-P-Goldfish Could you please create separate GH issue for this topic you mentioned and add the comment here with the link to that issue? TBH I am not 100% sure from the top of my head if DPoP is supposed to be used in other grant types besides authorizationCode. But it might be good to investigate this anyway...

@mposolda
Copy link
Contributor
mposolda commented Jun 5, 2024

@Captain-P-Goldfish Also it will be good to create dedicated GH issue for this issue itself with some more description. As every GH pull request (and commit) should have reference to the GH issue.

@Captain-P-Goldfish
Copy link
Contributor Author
Captain-P-Goldfish commented Jun 5, 2024

done.
I edited the comments above and linked the two issues:
Task: #30179
Bug #30181

@Captain-P-Goldfish
Copy link
Contributor Author

unit tests are fixed except for the flaky tests from the main-branch :-)

@mposolda
Copy link
Contributor

@Captain-P-Goldfish Thanks! Failing DockerClientTest seems like a regression of this PR?

@Captain-P-Goldfish
Copy link
Contributor Author

that should fix it. I am having serious trouble getting the DockerClientTest running locally due to ClassNotFound exceptions and an outdated testcontainers version that does not get along with my docker-desktop version... Is there somewhere a documentation that explains how to get this test running reliably?

The DockerClientLogin implementation was trying to get the ProtocolMappers which I extended by the DPoP ProtocolMapper and expected that the mappers were having only a single entry. I extended the stream by a filter that makes sure that only the expected mapper is returned.

@Captain-P-Goldfish
Copy link
Contributor Author

@mposolda are you going to review this or is someone else doing it?
If you would like to have any changes on this please let me know.

@mposolda
Copy link
Contributor

@tnorimat Does this PR look ok to you?

@mposolda mposolda requested a review from tnorimat July 16, 2024 10:00
Copy link
Contributor
@tnorimat tnorimat left a comment

Choose a reason for hiding this comment

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

@Captain-P-Goldfish I added some minor review comments. Could you check them?

Captain-P-Goldfish and others added 3 commits July 18, 2024 08:44
- tokenType must be DPoP as defined in RFC9449 chapter 7.1

relatesTo keycloak#22311

Signed-off-by: Pascal Knüppel <captain.p.goldfish@gmx.de>
fixes keycloak#30179
fixes keycloak#30181

Signed-off-by: Pascal Knüppel <pascal.knueppel@governikus.de>
Signed-off-by: Pascal Knüppel <pascal.knueppel@governikus.de>
@Captain-P-Goldfish
Copy link
Contributor Author

@tnorimat why do you want the documentation to be removed? I added it for those who read the code after us. People not knowing what DPoP is can find the related RFC and reasons why the code was added in this way faster if the comments are present. What is your reason that you want them removed?

@tnorimat
Copy link
Contributor
tnorimat commented Jul 18, 2024

@Captain-P-Goldfish Hello, IMO, removing comments are Keycloak's convention. When I sent the PRs implementing several RFCs with comments, I was requested to remove the comments.
@mposolda WDYT? If you are OK, keeping comments seems to be preferable.

Copy link
Contributor
@mposolda mposolda left a comment

Choose a reason for hiding this comment

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

@Captain-P-Goldfish Thanks! I've added small comment related to the refresh token constructor.

@Captain-P-Goldfish @tnorimat Regarding comments: I think comments in the code and also javadoc can be useful, but always depends on the context. It is not good if comments are mis-used and there is too much of them, but IMO comments are good if it makes the code more readable and adds the useful info why the particular code is used etc. So I think it is case by case.

AFAIK Keycloak does not have any strong convention on how much comments to use. Added the inline notes with some suggestions where comments can be useful IMO. For the other places mentioned by @tnorimat , I agree we can possibly remove comments.

What do you think?

*/
public RefreshToken(AccessToken token) {
public RefreshToken(AccessToken token, Confirmation confirmation) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it possible if you keep also the constructor with single refresh token argument just for the backwards compatibility? So possibly maybe just something like this:

public RefreshToken(AccessToken token) {
    this(token, null);
}

Signed-off-by: Pascal Knüppel <pascal.knueppel@governikus.de>
@Captain-P-Goldfish
Copy link
Contributor Author

I have removed the comments that were not commented by @mposolda and re-added the constructor.

Copy link
Contributor
@tnorimat tnorimat left a comment

Choose a reason for hiding this comment

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

LGTM

@tnorimat
Copy link
Contributor

@mposolda I approved the PR. Could you check it?

Copy link
Contributor
@mposolda mposolda left a comment

Choose a reason for hiding this comment

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

@Captain-P-Goldfish @tnorimat Thanks a lot for the reviews and applying all the comments from the review!

@mposolda mposolda merged commit 9478418 into keycloak:main Jul 29, 2024
74 checks passed
@Captain-P-Goldfish Captain-P-Goldfish deleted the dpop branch August 1, 2024 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[DPoP] token_type on UserInfoEndpoint expects Bearer instead of DPoP Support DPoP dynamically for all grant-types
3 participants
0