As becoming the de-fact, when asking users to authenticate, we change i.e. redirect to SSL. But then, if he/she opens another browser window and comes to us on http, to view two pages from our site simultaneously, on the second windows, he/she goes back anonymous. He/She has authenticated on the SSL i.e. https session, but not on http.
We first implemented this mechanism on SharePoint 2007. We may have wanted to redirect the second session to SSL so that the user finds himself logged-in on both windows. But due to some technical constraint not really of SharePoint, it was not that straightforward.
Anyway, this is how we started.
Then, when upgraded to 2010, we saw that the user is asked for username/password on the second session, even though the page that he is trying to open is anonymously accessible. After some research, we found out that this seems due to the WSS_KeepSessionAuthenticated cookie, that is sent. SharePoint forces the user to authenticate when it finds the cookie in the request.
To overcome, we created and hooked up a HttpModule to clear it at the beginning of the request made on http. It is an acceptable workaround for us, because we do not ask users to send their passwords as clear text.
Today, I found out that it is no longer needed with SharePoint 2013. The problem was that with SP2010, the cookie was set as non-secure. It is set when the user authenticates, and sent back to the server whether the session is secure or not. While with SP2013, it is set as secure when authenticated on https, and is sent back only when the communication is secured i.e. on SSL.
