Tolerate IDP time drift in devise config #53
Conversation
alanmacd06
assigned alanmacd06, bshand and miles-smith and unassigned bshand and alanmacd06
| @@ -281,5 +281,5 @@ | |||
|
|
|||
| config.saml_session_index_key = :session_index | |||
|
|
|||
| config.allowed_clock_drift_in_seconds = 1.second | |||
| config.allowed_clock_drift_in_seconds = 5.minutes | |||
There was a problem hiding this comment.
From the incident email thread and slack, can I confirm it resolved our end by this approach? I don't believe this occurred before, so the configuration in the email suggests clock drift was always a risk we have had all this time?
is 5 minutes excessive if we had 7 seconds of clock drift?
There was a problem hiding this comment.
Yes, this resolved the incident. It is arguably excessive, but given the anecdotal tales of ESXi guest behaviour with no NTP config (out by 30 minutes or more), I've made a judgement call. My own view is that, if someone is faking or high-jacked SAML responses given the trust relationship, we have bigger problems than extending the window of abuse by 5 mins.
Our own experience contradicts the anecdotal horror stories; we've always been running this 1.second tolerance and are not aware of any significant outages where the IdP has drifted beyond this, but given we're relying on user-reported issues, rather than granular data from the app itself, I'd be cautious of claiming "we've never seen clock drift before".
A running instance of the app experienced clock drift between it's host and the trusted IdP. The tight default tolerances in the default devise meant this broke SAML response validation when the IdP drifted ahead of the app host.
This PR relaxes the default config which, given the other controls in place in the only known deployment, should be pragmatic and safe