I must have missed an email from you Scott somewhere? I don't recall ever getting something from you talking about client "tolerance", and you guessed it, I wasn't aware of a client tolerance setting. Allowing a range of server_now - x seconds to server_now + y seconds allows for clock variance on the clients, as well as transmission delay. The range doesn't *necessarily* require that the *start* of the range equals the time that the response was generated. Why not make the response generation time somewhere inside the validity range? However, I defer to you guys who know a whole lot more than me about the specification of SAML response tokens. And thanks for that heads up on the client setting.
________________________________ From: Scott Battaglia [mailto:[email protected]] Sent: Wednesday, 16 June 2010 2:18 a.m. To: [email protected] Subject: Re: [cas-dev] SAML ticket validation I asked Dale if it worked fine for him. Its not clear from his email if he tried it or if he was aware of it. Switching the logic from the clients accounting to server drift (which in theory is only accounting for the drift of ~ two machines) to the server attempting to account for the potential drift of all clients doesn't really solve the issue. It just means you make the validity range valid before it was issued (which I'm pretty sure you probably shouldn't do) to potentially way after its intended lifetime in order to account for the multitude of clients. Ultimately its the client that is concerned with the validity of the assertion. Any client configuration to loosen restrictions around validation only affects the trust between the client and the server, whereas a change to the server configuration impacts all clients, whether they wanted it or not. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
