Our current federation setup is based on an ADFS 2.0 IdP with a number of web-based RPs based on WS-Federation / SAML-P 2.0 Web SSO. We are currently seeking to extend the web SSO federation to mobile devices.
During testing, we have found that all tested Android and Windows Phone devices (using their respective built-in browsers) works as expected. However, we found that some iPhone devices were prompting for credentials when attempting to switch between RPs. Further research have lead us to the conclusion that the reason for this behavior is a hard limit of 4K for cookie data per domain that is enforced by some versions of Safari – notably the newest versions running on iPhone and iPad, as well as Safari for Windows (v 5.1.5).
The MSISAuth cookies (of which there are always 3, chunked at 2K, at least with our setup) used by ADFS to “remember” the sign-in session exceeds this limit, causing at least one of chunks to be dropped by Safari. When the users browser returns to the IdP to extend the web sso to subsequent RPs, the session cannot be deserialized, and ADFS prompts for re-authentication.
Safari 3.1, the version tested by Microsoft at the time of ADFS 2.0 RTW (http://technet.microsoft.com/en-us/library/ff678034%28v=ws.10%29.aspx ), did not impose these limits, and is therefore not affected by this issue.
Exact steps to reproduce:
- Configure ADFS 2.0 with two web-based WIF RPs, RP1 and RP2.
- Using Safari for Windows (v 5.1.5) (or Safari for iPhone), browse RP1.
- Browser is redirect to ADFS 2.0 sign-in page
- Sign in
- A set of chunked MSISAuth cookies totaling in size past 4K is issued for the ADFS sign-in site.
- A token is POSTed to RP1, completing authentication for RP1
- Browse RP2.
- When the ADFS sign-on page is requested, at least one of the MSISAuth cookie chunks is missing and the web sso session cannot be deserialized.
Actual behaviour
The user is prompted to authenticate
Expected behavior:
A token should be POSTed to RP2 with no user intervention
This issue has been raised a couple of times on this forum already, but no workable solutions or workarounds have been found:
http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/6a56e279-ce5a-4ae4-8ef3-dec5c067d334
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/5fb2e2f5-0d3a-416a-9638-919495a58436
And of course, for the RP cookies, the solution is to use session mode for the cookies. However, this does not seem to be possible for the MSISAuth cookies:
http://blogs.msdn.com/b/vbertocci/archive/2010/05/26/your-fedauth-cookies-on-a-diet-issessionmode-true.aspx
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/dc1e178f-46ab-4567-88b8-1f2541744908
As such, my questions are:
- Is there any way to affect the size of the MSISAuth cookies, as to reduce their size to less than 4K total? (like the session mode of WIF, or through other means)?
- Does Microsoft support ADFS 2.0 web sso federation with current version Safari browsers on the desktop and on mobile devices? (if so, I believe this behavior is a bug)