Wednesday, 7 January 2009

SharePoint – Redirect to Secure Channel on Login

A couple of weeks ago, one of our IT guys was looking into hosting blog sites on Windows SharePoint Services 3.0 (using the CKS:EBE blogging engine – well worth a look). We started running through his requirements.

"We need read-only access for anonymous users." Fine.

"We need Forms auth accounts for contributors." No problem.

"We need to redirect users to a secure channel when they log in." OK, this is more challenging.

We can use Web application zones to support multiple access mechanisms, but how do we redirect users between zones when they sign in? This takes a little more trickery.

Let's start with a brief recap on SharePoint zones. Generally, there's a one-to-one mapping between a SharePoint Web application and an IIS Web site. The IIS Web site takes care of user authentication (for Windows auth at least), SSL certificate mapping, and so on. The SharePoint Web application takes care of authorization and serves up content. You can think of the IIS Web site as providing a specific route to the SharePoint Web application, through a specific URL, protocol (http vs. https), and authentication mechanism.

So, what happens if we want to provide more than one route to our SharePoint Web application? In the case of our blog site, we need to provide at least two routes – an http channel for anonymous access, and an https channel for registered users. In other words, we need to map our SharePoint Web application to at least two IIS Web sites. This is where zones come in – when you extend a SharePoint Web application to a new zone, you are effectively mapping it to an additional IIS Web site (with a corresponding configuration file).

In our case, we actually need three zones:

  • A default zone that uses Windows authentication to provide search support (more on this later).
  • An extranet zone to provide secure, forms-authenticated access to registered users.
  • An internet zone to provide read-only access to anonymous users.

So – why the redundant default zone? Because the SharePoint 2007 search service can't use forms authentication for search crawls. If you want to use forms authentication with SharePoint, you must still configure at least one zone for Windows authentication. Furthermore, the Windows authentication zone must be at the top of the list – if you configure the default zone for forms authentication, the search service will try this first and the indexing process will fail. In short, always configure your default zone for Windows authentication.

Now, let's get down to details. I don't want to reinvent the wheel here, so I'm going to assume you can create and configure the default zone and the extranet zone. If you're looking for walkthroughs on zones and forms authentication, the SharePoint Products and Technologies Team Blog has a good post here. In this post, I want to focus on how to redirect users between zones when they sign in.

So, we've got a default zone configured for Windows authentication. Our search service uses this zone to index our blog sites. We've also got an extranet zone configured for forms authentication. Our contributors use this zone to sign in over a secure channel and post content. Next, we need to create an internet zone that:

  1. Allows anonymous users to read blog entries.
  2. Redirects users to the extranet zone when they click Sign In.

Number 1 is straightforward. Number 2 gave me a headache. I looked at various ways of redirecting users on sign in. I tried customising the Welcome.ascx control in the Control Templates folder, but I wouldn't recommend opening that particular can of worms. As it turns out, all it requires is a minor change to the configuration file. First, here's a high level overview of how we configured our internet zone:

  1. Extend the Web application to a new zone, with a host header of
  2. Configure the policy settings for the new zone to deny write permissions to unauthenticated users.
  3. In IIS, enable anonymous access and Windows authentication (a temporary measure) for the Web site that corresponds to the internet zone.
  4. Browse to the site collection using the internet zone URL, sign in, and enable anonymous access at the site collection level.
  5. Go back to IIS, and clear all authentication types except anonymous access for the site that corresponds to the internet zone.
Now for the special move. Open the Web.config file for the internet zone Web site and locate the authentication element. It should resemble this:

<authentication mode="Windows" />

Change the authentication element to use forms authentication – but don’t add the connection strings, role manager details, membership provider details and so on. Set the login URL for the authentication element to point to the login page for the extranet zone:

<authentication mode="Forms">
<forms loginUrl="" />


This provides the behaviour we're looking for. If you access the site anonymously and click Sign In, you’re redirected to the secure URL and authenticated against the membership provider. You’re then redirected back to the same relative URL, but in the secure zone – e.g. if you were browsing, you click sign in and authenticate yourself, and you’re redirected back to Same page, different access mechanism.

How does it work? When the Sign In control redirects you to the login page, it includes the site-relative URL of the page you were visiting as a querystring. When you provide valid credentials, the login page will attempt to send you back to the page you came from – however, because it only has the site-relative URL, it has no idea which zone you came from. As a result, you're redirected to the correct page, but via the secure extranet zone rather than the original internet zone. The end result is you can only access the site anonymously over http, and you can only access the site as an authenticated user over https – perfect.


Samir said...


I found your blog today and tried to implement your excellent idea but it did not quite work out.

For the Internet zone, you have "Windows" authentication specified in SharePoint Administration. In the web config, you have "Forms" authentication (and the loginUrl for the login page).

For some reason, Windows authentication (challenge/response) is presented to the user even though "Forms" entry is in the web.config. I do not fully understand why we have "windows" authentication (in SharePoint Admin) and "Forms" in web.config.

I understand that the purpose of having the intranet zone is just to provide the redirection to the login page in the extranet zone (which has forms authentication configured).

Is there maybe a step that is not described in your post? When I enter the url for the intranet zone, I am invariably asked to authenticate with Windows authentication, even though "Forms" setting and LoginUrl are specified in the web.config.



Jason Lee said...

Hi Samir,

To avoid authentication prompts for the Internet zone, you need to ensure that you've enabled anonymous access both on the IIS Web site AND on the site collection. Once you've granted anonymous access on the site collection - which you must do through the Internet zone URL - you should disable Windows authentication for the IIS Web site in IIS Manager, leaving only anonymous access enabled.

So, why is the Internet zone set to use Windows authentication in Central Admin? Purely because if I specify forms authentication in Central Admin, I have to name the membership provider, the role manager, and so on. I don't have a membership provider or a role manager, because no-one actually gets authenticated in this zone - they're passed to the Extranet zone instead. Remember that Windows auth is managed by IIS, whereas in forms auth, the responsibilities for authentication are passed to the Web application itself. So setting the zone to use Windows auth in Central Admin is effectively saying to SharePoint "you don't need to worry about authentication, IIS will take care of it". Similarly, IIS has no interest in authenticating users in this zone - it's configured solely to permit anonymous access. Finally, the authentication element in the Web.config for this zone also does very little - it just ensures that when users attempt to sign in, they are redirected to the login page in the Extranet zone.

In short, everything should work as described if you've got anonymous access enabled in both locations - the IIS Web site, and the individual site collection under 'Advanced Permissions'. You won't be able to set anonymous access at the site collection level until its enabled at the Web app/zone level in IIS.

Hope that helps


Samir said...

Hi Jason,

After adding the correct AAM for the Intranet zone (and corresponding entry in the DNS), the issue was resolved.

Once again, thank you for the excellent post and clarification.

Cindy said...

Hi Jason,
Let say I have created 2 different authentication methods to access a site in ServerA

http://SERVERA/default.aspx [Zone = Default; Membership Provider Name = Windows]
http://internet/default.aspx [Zone =Internet;Membership Provider Name = AcAspNetSqlMembershipProvider, Form Based]

1) I want this http://SERVERA/default.aspx only can be accessed by internal staff via LAN. I managed to let the internal staff access to this URL by their own username and password from their own pc.

2)I want this http://internet/default.aspx can be accessed by Internet users. Currently, I can browse this url at the ServerA only. Can you guide me what are the step-by-step to configure the URL can be accessed by Internet users.

Looking forward your reply.

Cindy Tan

Jason Lee said...

Hi Cindy,

If you can browse your site through the internet zone from the server, it's probably not a SharePoint issue - more likely a DNS issue. I can't really advise on this, you need help from someone who knows your infrastructure.


Anonymous said...

great post Jason

is it trully nessisary to have SSL if all you are going to use is windows auth? Doesn't the user name and pass get encrypted using NTLM?

Jason Lee said...

Agreed - you don't need SSL to protect credentials if you're using NTLM, as the credentials will be encrypted anyway. I guess there are some scenarios where you might need a secure zone for other reasons, e.g. members-only forums or merchandising (okay, probably not on a blog site!)