I am integrating our Java Spring application with Okta SAML. From my understanding in Okta SAML request, it passes Okta user login time in "AuthnInstant" field. On Java Spring application we are using http://projects.spring.io/spring-security-saml/ plugin for SAML login. It does a validation on "AuthnInstant", see "response.assertion.authnStatement.authnInstant" session in this doc: https://docs.spring.io/spring-security-saml/docs/current/reference/html/configuration-advanced.html, which checks if "AuthnInstant" (aka Okta user login time) is within two hours. If further than two hours, reject the incoming SAML request.
If I understand correctly, default session lifetime of Okta is two hours "idle time". Which means in some cases when user is still active in Okta for a certain period after login, the total lifetime of the user's session can beyond two hours. In such scenario, when user tries to SSO to my application after two hours login time, Okta sends SAML request with AuthnInstant beyond two hours ago. My application rejects this request due to the above mentioned validation, which only accepts AuthnInstant within two hours.
After some googling, some threads suggest to extend spring SAML plugin validation on AuthnInstant to, for example, 1 day to handle such case. I would like to ask:
- if this is the best practise to handle the problem? Or any suggested length of period of the validation on AuthnInstant field? - AuthnInstant is equivalent to Okta user login time, through Okta login page or other API login method? - Any security drawbacks on extending the validation period?
Okta will send a value of the time of authentication for AuthnInstant.
I also recommend contacting Pivitol Software for support with your Java Spring application.
As for best practice, I've often used the rule of thumb that this is somewhat a balance for user convenience and security. Shorter periods being more secure and less convenient, and longer periods being less secure, but more convenient. Finding the right balanace can depend on your scenario.