Initial commit for maxSkew

[jackdent]

Added init-param for maxSkew, to remove bugs to do with out of sync clocks

[jackdent]

Have added default behaviour and units as requested.

[drt24]

Default behaviour is wrong, 0ms is too small, it will break all the time.

[jackdent]

I didn't want to set a default maxSkew and thereby expose potential relay attacks.

With no maxSkew set it was working fine on most machines that had some from of NTP configured.

[drt24]

Pretty sure that maxSkew has nothing to do with relay attacks, a relay could just use its own timestamp anyway. Many clients have clocks that are wrong buy surprisingly large amounts, 0ms is not the default used by raven normally and for good reason.

[jackdent]

Apologies that meant to read re_p_lay attacks - I doubted there would be an issue, but erred on the side of caution (I'm aware timestamping is sometimes used as a solution). What is the Raven default?

[drt24]

From http://www.ucs.cam.ac.uk/support/windows-support/winsuptech/iis/raveniismoduleconfig

Clock Skew Option

If you are unable to be certain of the time sync of a system which will be using your Raven authenticated service you can use the clock skew option in the Ucam Web Auth Config tab of the web server.

You should however be careful not to set too slack a value for this. 5-10 minutes maximum, 2-3 should be sufficient.