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

Clock skew leniency setting #181

Open
KalleOlaviNiemitalo opened this issue Dec 26, 2021 · 4 comments
Open

Clock skew leniency setting #181

KalleOlaviNiemitalo opened this issue Dec 26, 2021 · 4 comments

Comments

@KalleOlaviNiemitalo
Copy link

KalleOlaviNiemitalo commented Dec 26, 2021

Dependencies

JwtConsumerBuilder.setAllowedClockSkewInSeconds(int secondsOfAllowedClockSkew) has been available since jose4j-0.4.0~100.

Feature Request

Please add a setting that lets Jenkins accept the JWT from Azure AD even if the Not Before (nbf) time is a few minutes later than the current time of the server where the Jenkins controller is hosted. This would be a workaround for environments in which the clock of that server is synchronized from a local Active Directory domain controller whose clock lags behind the clock used by Azure AD.

With version 185.v3b416408dcb1 of the Azure AD plugin, clock skew like that causes the login to fail, and jenkins.err.log shows:

2021-12-26 13:52:02.148+0000 [id=12]	WARNING	o.e.j.s.h.ContextHandler$Context#log: Error while serving https://REDACTED/jenkins/securityRealm/finishLogin
org.jose4j.jwt.consumer.InvalidJwtException: JWT (claims->{REDACTED,"iat":1640526888,"nbf":1640526888,"exp":1640530788,REDACTED}) rejected due to invalid claims or other invalid content. Additional details: [[6] The JWT is not yet valid as the evaluation time NumericDate{1640526722 -> 26.12.2021 klo 15.52.02 EET} is before the Not Before (nbf=NumericDate{1640526888 -> 26.12.2021 klo 15.54.48 EET}) claim time.]
	at org.jose4j.jwt.consumer.JwtConsumer.validate(JwtConsumer.java:459)
	at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:304)
	at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:426)
	at org.jose4j.jwt.consumer.JwtConsumer.processToClaims(JwtConsumer.java:171)
	at com.microsoft.jenkins.azuread.AzureSecurityRealm.validateIdToken(AzureSecurityRealm.java:453)
	at com.microsoft.jenkins.azuread.AzureSecurityRealm.doFinishLogin(AzureSecurityRealm.java:393)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(Unknown Source)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:393)

The plugin configures the JWT validation settings here:

return new JwtConsumerBuilder()
.setVerificationKeyResolver(httpsJwksKeyResolver)
.setExpectedIssuer(expectedIssuer)
.setExpectedAudience(clientId)
.setRequireNotBefore()
.setRequireExpirationTime()
.build();

@KalleOlaviNiemitalo
Copy link
Author

It seems Azure AD already tries to prevent clock skew problems by making the Issued At (iat) and Not Before (nbf) claims five minutes earlier than the actual time of issue. However, this does not suffice if the clock skew exceeds five minutes.

@timja
Copy link
Member

timja commented Dec 26, 2021

Could the system get its clock fixed instead? 5 minutes is already quite generous

@KalleOlaviNiemitalo
Copy link
Author

Yeah I'm pursuing that solution as well.

@KalleOlaviNiemitalo
Copy link
Author

Got the clock fixed, but I'd still like to have this fallback available in case the problem recurs.

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

No branches or pull requests

2 participants