by zebsadiq
16. January 2012 10:52
It is such a simple and common requirement but it can be a nightmare to achieve out of the box with SharePoint. I spent quite a bit of time working out how a user can be authenticated via https and maintain their login cookie over http pages (without having to sign in again).
I initially setup the https url alternate access mapping as a public url of the extranet zone. Where as the http equivalent url was setup on the intranet zone. This was a little confusing as there was no authentication provider defined for the extranet zone and therefore the ‘Default’ zone’s authentication provider was being used. This was obviously incorrect as you are able to add private urls to the alternate access mapping mechanism, which allows you to have multiple urls defined for a zone. This is an important feature if your authentication provider is Forms Based Authentication (FBA).
Another odd behaviour of SharePoint FBA over mixed SSL is that if the http and https urls are only differ at the protocol level i.e. http://yourdomain vs https://youdomain , you will find that when you sign in over SSL (https), you are logged out of the non-SSL version of the SharePoint application and vice verse.
After much searching on the web, I found an article by Chris Coulson which discussed the issue in good detail and stated how to setup and work around certain issues. Much of my own findings and recommendations are documented here so rather than repeating what he’s written, I would recommend that you have a read of this: Mixed Http and Https Content with SharePoint 2010
Through Chris’s blog, I found a link to another post by Tim Nugiel, who has done a lot of good work in figuring out why exactly SharePoint FBA authentication behaves the way it does in a mixed SSL setup. Some people would call this a limitation of SharePoint but I see this as more of a bug as this limitation could have been avoided. Tim’s solution is to write a custom cookie handler that replaces the out of the box cookie handler, which is what I did and this allowed me to then share the authentication between the SSL and non-SSL versions of the same SharePoint application. I would suggest that you have a read of Tim’s post: Mixing it up w/ Mixed SSL & SP 2010
Final thought, if I couldn’t write custom code for my solution, it would have been impossible to achieve what I needed to achieve. Perhaps as a compromise, I may have had to make sure that the SSL sub-domain url for SharePoint application was different to the non-SSL version, e.g. http://www.yourdomain.com vs https://secure.yourdomain.com . This would only make sure that the login session for a particular mode of the application wasn’t lost if the user logged into the alternative protocol of the application.