OpenSaml4AssertionValidator is not respecting clock skew settings

[itsUmashree]

I am using Opensaml4AuthenticationProvider as an authentication provider in saml security filter chain, previously I was using old spring security-extension library, now we have migrated to spring boot 3.2.0 and saml2-service-provider to be 6.2.0.

I need to set clock skew as 30 mins, so I have customised the createAssertionValidator method to set clock skew. (By referring: #10263 (comment) )

But when saml response gets validated, it seems that first it validates the setResponseValidator(if any error it is added to saml2ResponseValidatorResult by concatting), again then assertion signature validator is executed which is actually private method, and this executes with clock skew as 5 mins which is default(then error is appended to saml2ResponseValidatorResult), and only then the customised createAssertionValidator() is validated and here I didn't see any error with invalid timestamps, as I customised the clock skew as 30 mins.

See :

spring-security/saml2/saml2-service-provider/src/opensaml4Main/java/org/springframework/security/saml2/provider/service/authentication/OpenSaml4AuthenticationProvider.java

Line 476 in 0364518

private void process(Saml2AuthenticationToken token, Response response) {

Because of the errors that are already added to the saml2ResponseValidatorResult object, it throws this error SAML20AssertionValidator - Assertion was not yet valid: IssueInstant: '2024-05-08T01:44:01.582Z', latest valid: '2024-05-08T01:38:25.918701912Z' and my application is not authenticated successfully .

Because to overcome this issue I am actually customising assertion validator to set clockskew for 30 mins but here it is appending and throwing the error, which is actually shows that dynamic parameters customised in assertion validator method is not considered or overriding the errors.

As a workaround If assertion signature validator api is exposed to public, I can override it and continue my saml validation with assertion validator.

[jzheaux]

Thanks for the report, @itsUmashree. It appears this bug was introduced in the 6.2.x line with an OpenSAML upgrade. The fix will go out in the next maintenance releases for 6.2.x and 6.3.x