Subscribe
Follow on Twitter Mixed Http and Https Content with SharePoint 2010
Have you ever wanted to have mixed https and http content in SharePoint? By that I mean a login page and user pages secured by https, while the rest of the content is delivered unsecured via http. Having the content either all http or all https is a breeze, but I wanted to be able to deliver both, and I ran into problem after problem. Here’s how it’s done, step by step:
Note: This tutorial is going to use the site created in the post Mixed Anonymous and Secure Content with SharePoint 2010. If you also want your site to have both anonymous and secured content (and I assume you do!), you may want to read that first.
1. Setup Https
I’m assuming that you already have your SharePoint web application setup and operating over Http. The first step is to enable it to operate over https as well.
- Open IIS and select your SharePoint Web Application from the list of sites.
- From the right-hand Actions menu, select ‘Bindings…’.
- From the Site Bindings dialog that opens, click ‘Add…’
- From the Add Site Binding dialog that opens, choose a type of ‘https’. This will default to a port of 443. You also have to select the SSL Certificate to secure the site with (You have to have already purchased an SSL certificate, or generated a private one). Click OK and close the Site Bindings dialog.
2. Configure SharePoint to use Https
In addition to configuring https in IIS, SharePoint also has to be configured to recognize the https address.
- Open SharePoint Central Admin and select ‘Application Management’, ‘Configure Alternate Access Mappings’
- Select your Web Application from the ‘Alternate Access Mapping Collection’.
- Click ‘Add Internal URLs’
- Enter the https URL for your site. Make sure that the same zone is selected that you access the http version of your site from.
- Click OK.
If you try to browse the site, you’ll notice that you can now browse the site from both the http and the https addresses. There are still a couple of issues though. While browsing the https version of the site, some actions (such as signing out) will bring you back to the http version of your site. Also, if you login using https and then browse an http page, you’ll notice that you’re no longer logged in. We’re going to fix these issues in the next couple of steps.
Note: If you want ALL of your site content to be delivered via https, and don’t care about mixed content: instead of adding an internal URL, simply edit the public URLs and change the address to https and YOU’RE DONE! No need to continue with the rest of this tutorial.
This is also the step that caused me the most grief when initially configuring my SharePoint site for mixed http and https. I had initially placed my https URL under the Custom zone of Edit Public URL’s. Since I only had one actual zone (the default zone, as I hadn’t extended the web application into multiple zones), the URL in the custom zone would point to it, which I thought would be OK. However with this configuration I was always asked to authenticate when switching between http and https. The problem was that even though there is only one REAL zone, SharePoint was interpreting the address change as switching between the default and custom zone and was forcing the user to re-authenticate. This is why we add an internal URL for SharePoint to recognize, instead of editing the public URL’s.
3. Configuring SharePoint’s Authentication Cookie
Notice that even if you authenticate via https, your authentication isn’t recognized when you switch over to http. The reason for this is because SharePoint has hard-coded logic that says if it’s generating an authentication token for an https connection, then turn on the SSL Only flag on the cookie. An SSL Only flag means that the cookie can only be accessed via https. So as soon as you change the address to http, your authentication cookie is no longer recognized and you have to login again.
Tim Nugiel found the solution to this problem. He wrote his own cookie handler that override’s SharePoint’s behaviour. See his post for directions on configuring this:
Mixing it up w/ Mixed SSL & SP 2010 (The original link appears to have gone offline)
Mixing it up w/ Mixed SSL & SP 2010
You should now be able to authenticate via https, and stay authenticated while browsing content either via http or https – we’re almost there!
4. Redirecting users to Http or Https
The only issue remaining is forcing certain content to be viewed via http or https. Right now users can access your login page via https, but there’s nothing forcing them to. They could also access it via http. The same goes for any other content you want to secure. To solve this problem we’re going to set up some redirect rules using the IIS 7 URL Rewrite module.
- Install the IIS7 URL Rewrite module. You can download it from here: http://www.iis.net/download/urlrewrite
- Open IIS and select your SharePoint Web Application from the list of sites.
- Open the Url Rewrite module from the Features View.
- Click Add Rules…
- Select ‘Blank Rule’ under ‘Inbound Rules’ and click OK.
- Fill in the name with ‘HTTP to HTTPS Redirect’.
- Set the Pattern to: ^(_forms/default.aspx|user/pages/.*aspx)
- Add the condition: Input: {HTTPS} Check if input string: ‘Matches the Pattern’ Pattern: off
- Set the Action Type to ‘Redirect’
- Set the Redirect Rule to: https://demo2010a/{R:0} (Substitute for your own url)
- Set the Redirect Type to ‘Permanent (301)’
- Click ‘Apply’ and click ‘Back to Rules’.
What the rule we created says is:
If the url starts with /_login/Default.aspx (The default FBA login page) or /User/Pages/anypage.aspx (any page in the Pages library of our User site) AND if https is not being used THEN send back a Permanent Redirect to the https URL, using the original URL after the server address.
Now we’ll create a second rule that says all of the pages on the main site should be accessed via http. The reason we need this rule is because once we’re browsing over https, any relative URLs in the page will also be accessed over https. So if we want certain pages to be consistently delivered over http, we need a rule to force this:
- From the IIS Rewrite module, add another blank inbound rule.
- Fill in the name with ‘HTTPS to HTTP Redirect’.
- Set the Pattern to: ^pages/.*aspx
- Add the condition: Input: {HTTPS} Check if input string: ‘Matches the Pattern’ Pattern: on
- Set the Action Type to ‘Redirect’
- Set the Redirect Rule to: http://demo2010a/{R:0} (Substitute for your own url)
- Set the Redirect Type to ‘Permanent (301)’
- Click ‘Apply’ and click ‘Back to Rules’.
What the rule we created says is:
If the url starts with /Pages/anypage.aspx (any page in the pages library of our root site) AND if https is being used THEN send back a Permanent Redirect to the http URL, using the original URL after the server address.
This is just a simple example of what can be done with the IIS Rewrite Module. It is very powerful and allows to you to develop very complex rules that can handle almost any redirection you’d like.
That’s it! You’re done! You can now login to your site over https and force content to be read over http or https based on rules.
I want to thank Tim Nugiel for taking time out of his busy day to help me troubleshoot issues I was having getting this to work. Tim had the only working example of this that I was able to find on the internet. He also developed the SSL Only cookie handler solution. Thanks for all your help Tim!
25 Responses to “Mixed Http and Https Content with SharePoint 2010”
Leave a Response
Trackbacks
-
[…] creating a custom cookie handler for mixed mode authentication. I reference it in my blog post Mixed Http and Https Content with SharePoint 2010. The original article was posted at: http://www.msngn.com/blog/lists/posts/post.aspx?id=5. […]
-
[…] Mixed Http and Https Content with SharePoint 2010 http://blogs.visigo.com/chriscoulson/mixed-http-and-https-content-with-sharepoint-2010/ […]
Thank you for putting this article together. It’s a great service when people take the time to share this information. I’m in the process of trying to do the same – just have to find the time 🙂
I’ve implemented the IIS URL Rewrite rules together with the code modifications required (extending the SPChunkedCookieHandler).
When I go to my site (development site on test server), it comes up fine (http). Click on SIGNIN and it hits the overwritten SPChunkedCookieHandler.DeleteCore method. The login page is displayed correctly (https).
When you login, it hits the SPChunkedCookieHandler.WriteCore which flips the secure value from true to false. This all works fine.
If I specify an additional page to flip to https (in IIS URL Rewrite rule) after the user is logged in (e.g. purchase.aspx), I get “The page cannot be displayed”. The error in the IIS log has the following error codes at the end of the log entry “301 0 0 203”. If I’m interpreting this correctly, the 203 is “The information received is not from the server that the information was requested from, but from another source.” Is this because the WriteCore method is not hit and the secure value not toggled? Doesn’t the token have to be set to true or false depending on whether going from http -> https or https -> http?
Thanks for your help . . .
I’m not sure if you mean the SSL Only flag on the cookie, or the HTTPS flag on the rewrite rule.
The SSL Only flag on the token should always be set to false. Setting it to true means that the value will only be accessible via an https session, so the token will no longer exist as soon as you change to http.
As for the rewrite rule, you use the HTTPS flag to decide whether to run the rule. You’d only want to run an HTTPS -> HTTP rule if the HTTPS flag was true, and vice versa.
To determine if the rewrite rule is causing the error, turn off the url rewriting and see if you can flip between the addresses manually. If you can, then there’s a problem with your rewrite rules.
I just typed up a scenario and question to better understand the secure cookie flag being passed into the WriteCore method and then I realized what you’re saying.
The secure flag doesn’t act as a toggle but allows the cookie to be used both as a secure and non-secure cookie. I was thinking that a secure cookie would be used and then a non-secure cookie would be used (thus invalidating the secure cookie) and so on and so on . . . This didn’t make any sense to me.
As you suggested, I will look at my rule definitions since it seems the problem is there.
Thanks again for you help.
Tom
I got it to work. Here is what I found. I had originally created a document library below the Pages document library called secure. For the HTTP->HTTPS rule, I had
^(_layouts/customloginpage.aspx|Pages/secure/.*aspx)
and for the HTTPS->HTTP rule, I had ^pages/.*aspx. The pages in the secure doc library would not display with the error I had mentioned in my earlier response.
I eventually created a doc library (called secure) at the same level as the Pages doc library and changed my HTTP->HTTPS rule to
^(_layouts/customloginpage.aspx|secure/.*aspx) and this works perfectly.
I’m not sure whether this problem is with SharePoint or my IIS rules. The IIS rules seem pretty straight forward so I don’t think it’s the rules. Well, we can always blame it on SharePoint 🙂
Thanks one more time for your help.
Tom
Hi Chris,
Thanks for your excellent post here, it helped me a lot. It took me ages to find it for some reason. Thats why I’ve written my own post, sharing my experience with a link this post. You can find it here.
http://blog.zebsadiq.com/post/Achieving-partial-mixed-mode-(http-and-https)-FBA-in-SharePoint-2010.aspx
Thanks again,
Zeb
Thanks for your nice post ^-^
I followed below mentioned links :
http://www.sp2010hosting.com/Lists/Posts/Post.aspx?ID=5
2. http://blogs.visigo.com/chriscoulson/mixed-http-and-https-content-with-sharepoint-2010/
3. http://www.sharepointconfig.com/2010/04/partial-ssl-sharepoint-sites-login-over-http-from-http-pages/
In my case cookie FeAuth is set back to Http , but user is not actually logged in.
Steps I followed:
1. Extended the current setup on SSL . Made it working similar to the default zone application ( including resource files and web.config entries,manual dll etc.)
2. Set the postback url for login button.
3. Made the URL rewrite entries as suggested in both zones. ( these are spread across multiple links, REQUEST_METHOD is additional to https ON rule) URL rewriting can be done very easily with an IIS extension provided by Microsoft.
4. Created the custom handler as suggested and replaced it with SharePoint one.
5. Set the required SSL for cookies to false, so that they may be used on non ssl also.
Related post :
http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/2a3ac89e-334b-4341-9f8e-dc9a01962466/#ea01e65f-5f7d-4d12-8c6e-0d131d2ccb67
Related post :
http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/2a3ac89e-334b-4341-9f8e-dc9a01962466/#ea01e65f-5f7d-4d12-8c6e-0d131d2ccb67
Great article. Very nice information.
Thanks a Ton
Hi,
Very nice article. However, if we want to use ADFS 2.0 for the authentication solution, is it possible to apply this method by only using HTTPS to perform the authentication to ADFS server and switch back to HTTP once the user is authenticated and authorized to access the Sharepoint site? Is the cookie produced by ADFS going to be work over HTTP?
Thanks in advance if you have ever done it.
I’ve never worked with ADFS myself, but I would expect the steps in the above article to work the same. Let us know how it goes.
Just one note on step 3. From a security perspective, it’s a bad idea to send authentication cookies over an HTTP connection.
An attacker could steal it (especially when using a public Wifi connection), and use it to usurp the user’s identity.
The rest of the post is very interesting.
Hi,
Tim Nugiel’s solution is not opening. Could you give me working url? Thanks for the article
Yeah, it looks like his whole site is down. Hopefully it will be up soon. In the meantime, you can check the google cache results:
http://webcache.googleusercontent.com/search?q=cache:RlmcILZXJjEJ:www.sp2010hosting.com/lists/posts/post.aspx%3Fid%3D5+&cd=2&hl=en&ct=clnk
This is a wonderful post. Is there a similar solution for II6 used with Sharepoint 2007?
Not that I know of. The IIS setup should be the same. The only thing that might be different would be the cookie handler. Of course maybe you’ll be lucky and SharePoint 2007 won’t mark the cookie SSL only.
i m trying to open Tim Nigiel solution is not opening even the google cache results, can you please provide me with the steps cooking handler
Thanks for letting me know! I managed to find a cached page of the article and reposted it here. The article has been updated.
Thanks a lot for your quick reply
Great article, but have you tried getting the entire SP farm with Mysites and Office Web Apps server to work under http internal network and https external (internet access)? I’m working on a new build, have been searching all over for SP, mysites and office web apps all configured for HTTP and HTTPS, and I haven’t found one article on it. It also appears office web apps will only work with either HTTP or HTTPS, so I’m going to have to configure the entire farm for HTTPS. Poor documentation by Microsoft and none of the fixes i’ve tried for Office web apps work.
I have not tried this with Office Web Apps.