Azure SSO - Authentication issue instant is too old or in the future

[Tomer Praizler]

Hey, 

I get this famous error message: Authentication issue instant is too old or in the future

Following pac4j saml documentation: http://www.pac4j.org/docs/clients/saml.html I set the maxAuthAge to 8 hours, but the problem is that Azure configuration is different than ADFS.

Looking in azure documentation: 

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes -> Single sign-on session tokens it looks like the session should be configured to 24 hours and not 8.

I am trying to understand if there is any damage in configuring the setMaximumAuthenticationLifetime to 24 hours, instead of 8. Will it break anything?

Thanks!

[Anton Piatek]

I think the only thing it means is that the saml token will be valid for much longer. In theory this increases the range for a replay attack, but it is all https communication so if that is compromised you've bigger problems

[Tomer Praizler]

Cool. Thanks.

[Tomer Praizler]

Looks like I still get this error: org.pac4j.saml.exceptions.SAMLException: Authentication issue instant is too old or in the future

    Event after I set the max auth lifetime to 24 hours. 

Any idea what can I do? or check? maybe this is azure configuration?

On Wednesday, 21 June 2017 11:14:25 UTC+3, Anton Piatek wrote:

[Anton Piatek]

If you get a proxy in place (like fiddler) or even something like chrome debug tools, you can see the SAML assertion sent down to pac4j. If you pull that out and base64 decode it you can read the XML to find the actual timestamps - It is worth checking these make sense and that all your computers have the correct time and timezone

(not sure about azure, but ADFS has an option to encrypt the saml token which would make this step impossible, turn it off for testing if you can)

[Lior Harel]

Hi.
I'm also having the same issue. Not only with Azure, also with Okta SAML.

I've enabled the TRACE logs for pac4j, as the error suggests the issue instant is indeed old, I've seen instances issued 2-3 days before, one time even a month old.

So the error is correct. What I don't understand is how this should be resolved. Can I instruct the IDP in the initial request not to reply with old instances? if not, can I redirect back to the IDP after the failure to refresh the auto instant?

or should I just increase the value to a value large enough?

The strange thing is when checking the azure session timeout it is 24 hours, yet I see instances issued earlier.

Thanks

[Jérôme LELEU]

Hi,

There is an authenticationMaximumLifetime property you can use.

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to the Google Groups "Pac4j users mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jaroslav Kačer]

Hello everybody!

We also faced the same problem with MS Azure AD.

Based on what I read about tokens in AAD, I think they have something like "sliding validity" - as long as the user keeps using it, its being kept valid by AAD. So you can get really old Issuance Instances in your assertions. (I can provide a link to MS documentation, should you need it.)

We solved the problem by setting the maximum authentication lifetime to MAX_INT / 2, which is about 34 years or so... And it works.

Best Regards,

    Jarda

[Sanchit Choubey]

Hi All,

@Jaroslav setting max auth lifetime to this long time is not really a good idea. I am also facing this problem in our application.

@Jérôme : Isn't there any variable which we can set and control the Azure integration to retrieve the fresh token if it is expired within the one hour timeframe which is the  default value of max auth lifetime.

 

Thanks,

Sanchit

[Jérôme LELEU]

Hi,

If need be, you can override the isExpired method from the OidcProfile to implement your own behavior.

There have been some adjustments on this in the latest v4.0.x versions.

Thanks.

Best regards,

Jérôme

--

You received this message because you are subscribed to the Google Groups "Pac4j users mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-users/04a44881-a646-4825-af12-cde326256414n%40googlegroups.com.