Mixed Anonymous and Secure Content with SharePoint 2010

In this tutorial i’m going to step you through how to set up a SharePoint 2010 publishing portal with both anonymous and secure content.

1. Create a new Web Application in Central Admin. Make sure that you select ‘Yes’ for Allow Anonymous. All other values can remain at the defaults. For this example I’m going to use FBA Claims based authentication.

2. Using central admin, create a site collection on the web application you just created. In this example I’m creating a publishing site.

3. Visit the site you just created. You will be asked to authenticate. This is because even though ‘Allow Anonymous’ was turned on at the web application level, it still has to be specified at the site level. You will be shown the default home page.

4. First we’ll create a new Home page that will be the page anonymous users will see when they first access the site. From Site Actions, choose New Page and call it “Home”. When the new page appears, just type in a quick welcome message and save it.

 

5. With a publishing site the content will need to be both published and approved before it will be visible by anonymous users. To publish the page, click ‘Submit’ on the ‘Publish’ tab and follow the wizard. Once the submission is complete, approve the page by clicking ‘Approve’ on the ‘Publish’ tab and follow the wizard. Note that to approve the page, you will first have to add your user to the ‘Approvers’ group under ‘People and Groups’ in ‘Site Settings’. The page is now published, and will be visible to anonymous users once we enable anonymous access.

Note that any resources that have been added to the page, such as images from the Images library, will also have to be published and approved before they can be viewed by anonymous users.

6. Under ‘Site Settings’, ‘Welcome Page’ set the welcome page to be the new ‘Home’ page we just created.

Now when we got to our site root page, we’ll be redirected to the ‘Home’ page we just published. If you sign out and visit Pages/Home.aspx, you’ll notice that you’ll be prompted to enter your credentials, so we still need to enable anonymous access to the page.

7. Sign back in to the site. Go to ‘Site Settings’, ‘Site Permissions’. Click on ‘Anonymous Access’. From the ‘Anonymous users can access: ‘ dialog, choose ‘Lists and Libraries’ and click OK. Alternatively you can click ‘Entire Web Site’, which will make everything available anonymously, however I prefer to define exactly which resources have anonymous access. By choosing ‘Lists and Libraries’ your entire web site is still secured. You have to directly configure each List/Document Library to enable anonymous access. If you sign out and visit Pages/Home.aspx, you will notice that you will still be prompted to authenticate to view the page.

8. Now anonymous access needs to be enabled on the ‘Pages’ library. Go to ‘View all site content’, ‘Pages’. Click ‘Library Permissions’ on the ‘Library’ tab. Click ‘Stop Inheriting Permissions’. Click ‘Anonymous Access’. Select ‘View Items’ in the ‘Anonymous Access’ dialog and click OK. Now all of the content in the ‘Pages’ library will be accessible anonymously. Note that you can ‘Manage Permissions’ and ‘Stop Inheriting Permissions’ for individual items (including folders) in the library, if you want to prevent them from having anonymous access. Unfortunately you cannot enable anonymous access on individual items, only the whole library.

Now if you sign out of the site and visit Pages/Home.aspx, you’ll be able to view it and won’t be prompted to authenticate.
9. There’s another problem you might notice. Home.aspx is our default page, and allows anonymous access, however if we visit the site root we’re still prompted to authenticate. This is because we chose the more secure option of allowing anonymous access on ‘Lists and Libraries’ instead of the ‘Entire Web Site’. PowerShell needs to be used to allow anonymous access to the site while keeping the ‘Lists and Libraries’ settings. Run the following PowerShell commands (based on instructions from http://stackoverflow.com/questions/1338809/anonymous-access-to-a-sharepoint-site-root) - substitute your own SPWeb address:

view source

print?

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$web = Get-SPWeb http://demo2010a:42076

$web.AnonymousState = [Microsoft.SharePoint.SPWeb+WebAnonymousState]::Enabled

$web.AnonymousPermMask64 = "Open, ViewPages"

$web.Update()

Note that if you look at ‘Anonymous Access’ under ‘Site Permissions’, it will say ‘Entire Web Site’ – however you will still need to explicitly specify which lists and libraries have anonymous access, just as if it was set to ‘Lists and Libraries’.
Now if you sign out and visit the root of the site, you should be redirected to Pages/Home.aspx and not asked to authenticate. We finally have controlled anonymous access!

10. The other part of this tutorial is to show you how to have secure content mixed in with your anonymous content. Now that you can control which content is available anonymously, adding secure content is very straightforward. I had mentioned earlier that you can secure content within a library with anonymous access by clicking ‘Stop Inheriting Permissions’. The problem with this is that by default a document will have anonymous access, and you will have to specify exactly which documents are secure. For that reason it’s better to keep secure pages in their own library with anonymous access turned off. For this tutorial we’re going to create a child site called ‘User’. It’s ‘Pages’ library will not allow anonymous access, so all of it’s content will be secured.
Select ‘Site Actions’,'New Site’ and create a new ‘Publishing Site with Workflow’ called ‘User’. Click Create.

11. Edit the default page and add some custom content. Save, Publish and Approve the page.

As the new site’s Pages library is secured by default, nothing additional has to be done to secure it. Notice that if you sign out and visit the site root, you can still access Pages/Home.aspx (although you won’t see a link to the User site). If you attempt to access ‘User/Pages/default.aspx’, you will be asked to authenticate.

Congratulations! You now have a SharePoint 2010 site with both mixed and secure content.

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:

SharePoint’s behaviour. See his post for directions on configuring this:
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.

First we’ll add a rule to redirect secure content to https. For this example our secure pages will be the login page and the pages in our ‘User’ site:

• 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.