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

[Token/JWT] Add some leeway to jwt claims #19796

Closed
wants to merge 5 commits into from

Conversation

an-toine
Copy link
Contributor

@an-toine an-toine commented Jan 4, 2024

Comprehensive Summary of your change

On distributed systems, with Harbor deployed on multiple backend servers, it is not uncommon to observe some small discrepancies between server clocks, even with a reliable NTP source.

In such cases, a backend server may issue tokens with a NotBefore field set to a future timestamp for other servers, resulting in failed (403 unauthorized) image pulls for end users :

[ERROR] [/pkg/token/token.go:68]: parse token error, token is not valid yet

As RFC7519 tolerates some leeway to be provided to account for clock skew, this PR is adding/substracting 10 seconds to fields NotBefore, ExpiresAt and IssuedAt.

With golang-jwt v5.2.0, a leeway field is directly integrated in the Validator struct (https://github.com/golang-jwt/jwt/blob/v5.2.0/validator.go#L38). This PR is just emulating this behavior for the release currently in use in Harbor.

Issue being fixed

Fixes #18880

Please indicate you've done the following:

  • Well Written Title and Summary of the PR
  • Label the PR as needed. "release-note/ignore-for-release, release-note/new-feature, release-note/update, release-note/enhancement, release-note/community, release-note/breaking-change, release-note/docs, release-note/infra, release-note/deprecation"
  • Accepted the DCO. Commits without the DCO will delay acceptance.
  • Made sure tests are passing and test coverage is added if needed.
  • Considered the docs impact and opened a new docs issue or PR with docs changes if needed in website repository.

@an-toine an-toine marked this pull request as ready for review January 4, 2024 17:25
@an-toine an-toine requested a review from a team as a code owner January 4, 2024 17:25
@Vad1mo Vad1mo added the release-note/update Update or Fix label Jan 4, 2024
@Vad1mo Vad1mo enabled auto-merge (squash) January 4, 2024 17:47
@Vad1mo
Copy link
Member

Vad1mo commented Jan 4, 2024

Thank you for your contribution @an-toine, can you check if we could upgrade our dependency golang-jwt from v4 to v5?

Copy link

codecov bot commented Jan 4, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8c0f177) 67.54% compared to head (afec633) 67.54%.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##             main   #19796   +/-   ##
=======================================
  Coverage   67.54%   67.54%           
=======================================
  Files         991      991           
  Lines      109171   109173    +2     
  Branches     2719     2719           
=======================================
+ Hits        73739    73741    +2     
+ Misses      31467    31465    -2     
- Partials     3965     3967    +2     
Flag Coverage Δ
unittests 67.54% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
src/core/service/token/authutils.go 69.79% <100.00%> (+0.64%) ⬆️

... and 4 files with indirect coverage changes

@an-toine
Copy link
Contributor Author

an-toine commented Jan 5, 2024

Thank you for your contribution @an-toine, can you check if we could upgrade our dependency golang-jwt from v4 to v5?

I've opened #19802 to migrate to golang-jwt v5.2.0 and use the built-in leeway attribute.

auto-merge was automatically disabled January 11, 2024 16:49

Head branch was pushed to by a user without write access

Signed-off-by: Antoine Jouve <[email protected]>
@MinerYang
Copy link
Contributor

MinerYang commented Jan 17, 2024

Hi @an-toine ,

We probably do not need this PR if we prefer to add our leeway at the validate side. Let's focus on review the another PR

@MinerYang MinerYang closed this Jan 17, 2024
@an-toine
Copy link
Contributor Author

Hi @an-toine ,

We probably do not need this PR if we prefer to add our leeway at the validate side. Let's focus on review the another PR

@MinerYang : fully agree, I will try to work on #19802 review by the end of the week.

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.

6 participants