Anyone who has worked with SAML knows very well how effective and simple it is to achieve federated services with your own authentication mechanism. What needs to be remembered, though, is that end-users might very well be behind firewalls. And with that come proxies; and those proxies open up the Pandora’s box aka cache.
Proxies can cache POST response from the authentication user agent and make user1 see a page which says ‘Welcome user2′. Do a forced-refresh (Ctrl-F5, Cmd-R) on the browser, and you can see your own ID again.
Fixes:
1. Ensure proxies don’t cache any content for your authentication domain.
2. Pass a ‘random’ value like the timestamp using Javascript to the URL (to make it unqiue)
3. Force the content-provider’s web server, and the user agent web server to set Cache-Control to max-age=0 and proxy-revalidate.
4. Make sure you’re sending an invalidation string in the packet as well.
Clearing proxies in a company with about ~100 proxy servers might not be the right choice. The onus should lie on the development and the sysadmin team to make sure
important pages are non-cacheable.
Proxies can cache POST response from the authentication user agent and make user1 see a page which says ‘Welcome user2′. Do a forced-refresh (Ctrl-F5, Cmd-R) on the browser, and you can see your own ID again.
Fixes:
1. Ensure proxies don’t cache any content for your authentication domain.
2. Pass a ‘random’ value like the timestamp using Javascript to the URL (to make it unqiue)
3. Force the content-provider’s web server, and the user agent web server to set Cache-Control to max-age=0 and proxy-revalidate.
4. Make sure you’re sending an invalidation string in the packet as well.
Clearing proxies in a company with about ~100 proxy servers might not be the right choice. The onus should lie on the development and the sysadmin team to make sure
important pages are non-cacheable.
Never trust proxy servers is the motto here. More Here
Courtesy:http://mohitsuley.wordpress.com/