At first, I was thinking about naming this blog post "Can It Really Be That Stupid?" After a few seconds, I realized the answer is "Yes.", got over it, and moved on. For one thing, I would have to decide which thing was *that* stupid, and that's just asking too much.

So, there are a number of people out there using SharePoint with WLA. It seems like a cool concept. Just use the WLA membership and role providers the way you would any provider for forms based authentication, and "Voilla!" your friends or business partners on Live Messenger can log in to your site using their Live ID , whereupon you can give them special access.

Last year, the Community Kit for SharePoint released a WLA membership provider designed to be used with the Enhanced Blog Edition. If you're curious - and very brave - you can get the source code from CodePlex here. The solution comes with a readme, which leaves out a couple of minor steps, but Rolf Eleveld has a nice walkthrough with screenshots on his blog.

Oh, if only it had actually been that easy!

Access Denied Errors on Login for LiveAuth-Handler.aspx

After following all the instructions to set up WLA, I tried to log in on the public facing site by clicking the Sign In link, but I kept receiving the "401 UNAUTHORIZED" error. A quick check of the IIS logs reveleaded this as "HTTP 401.5: Denied by custom ISAPI/CGI Web application", which means that the access issue is occurring within SharePoint itself.

There are so many causes for this kind problem, but I remembered solving such an issue about a year and a half ago. Here are some of the things you can try if you are having 401 problems.

1. Disable Loopback Checking
   This security "feature" is enabled by default with the latest service packs, but it was not really meant to be used in SOA environments like SharePoint. Basically, whenever SharePoint attempts to hit its own web services on the local machine, IIS will block the attempt and cause SharePoint to throw an Access Denied error. The issue described in the Microsoft KB Article is not exactly what I was seeing, but it contains instructions on how to perform the registry hack. In the past I have seen this problem cause unusual symptoms within SharePoint that you normally wouldn't see in a vanilla ASP.net application, so I wouldn't rule it out.
   
2. General Tips for 401 Errors in IIS
   You can also try some of the things suggested by this Microsoft KB Article. It has useful links to some diagnostic tools including the AACD 1.0 and FileMon. At the very least, following this approach should help to uncover any typical problems that would interfere with any SharePoint install, with or without CKS.
   
3. SharePoint File Permissions
   Make sure you have all the correct file rights set up for the anonymous (IUSR_MACHINE) and application pool accounts. You can use FileMon to test for this (see above). This will include rights to the ASPX files in the LAYOUTS folder, including special anonymous access permissions that are needed for Login.aspx, Authenticate.aspx, and in our case LiveAuth-Handler.aspx. Generally, if you have IUSR_MACHINE in the WSS_WPG group, and the application pool account in the WSS_ADMIN_WPG group, then that ought to do it.
   
4. Is Your Provider Working?
   Make sure your authentication provider is set up correctly. In this case, I would double check the setup as per the instructions described with the WLA provider above.
   
   One way to test this is to add the same provider settings to your internal (Windows Authentication) and Central Administration sites. With these added, you should be able to go into your windows authentication based site and add Live Authenticated Users as a group with rights within SharePoint – even if you can't successfully get the Live ID login process to work.
   
   
   Figure: Testing correct setup of WLA Users and Groups from the intranet (Windows Auth) site
   
   In my case, I added the membership, roleManager, and appSettings nodes to the web.config file located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG, because I wanted these providers to be accessible to every web application on my development machine. However, I will probably go "by the book" in production.
   
   Also, note that I have commented out the identity node (namely, impersonation="true") in the public facing (FBA) web.config file, as this is normal practice for FBA sites, but wasn't mentioned in the WLA documentation.

Unfortunately, none of these things I tried actually solved my problem. Every page I would try to visit would redirect me to Authenticate.aspx, and then that would subsequently 302 redirect me to LiveAuth-Handler.aspx?action=login, which would give me the same 401 error.

As a quick aside, let's look at how the login process actually works, because I was thinking about it a lot at the time. We start on the main page of the blog, and if you have Anonymous Access configured in SharePoint and also correctly configured in IIS, then you'll see the default.aspx page with its Sign In link displayed correctly.

As you can see, this link takes you to Authenticate.aspx, which is SharePoint's default page for requiring a login, and the one that is responsible for redirecting you to LiveAuth-Handler.aspx as described in web.config, whereupon, we get the dreaded 401.5 error. Authenticate.aspx seemed to be working as designed, but I was at a loss to explain the error.

My Eureka Moment: Running Out Into the Street without My 401

After a full day of beating my head against the machine I was getting a bit crazy, so I decided to take a break. I put the computer away and went to an Orioles game with a pal of mine. Perhaps my best tip of the day, do not underestimate the value of taking a break. Your brain will keep working on the problem in the background while you recharge your batteries. In fact, I had a great time. Not only was this the first time in over a decade that they won while I was at the stadium (what awful luck!), but they delivered a spectacular grand slam followed by a three run homer, literally crushing the Cleveland Indians.

So, the following morning I was thinking about what is different in the WLA that I have never seen in any FBA based solution before. If I could find the variables, and eliminate them, I might solve the problem or at least discover the cause. One thing that struck me as just-too-stupid-to-think-about was the URL that specified in the loginUrl attribute of the forms tag in the authentication section of web.config.

"What if," I thought, "however unlikely it may be, there is something in the .NET authentication provider that refuses to recognize the login page simply because it can't handle the query string at the end?" Well, it sure seemed like the kind of shortcoming that would typically sneak into code, but I had never heard of such an issue. Still, there are lots of patches both for .NET framework and SharePoint, so maybe I'm on a patched version that has this rare problem.

So, I tried a little experiment. I took out the query string, like so.

Click the Sign In link again, and…

"Wow! There's no way it can be that simple." I put the query string back into the web.config, then tried to log in again, just to be sure.

In fact, if you take the query string out of web.config, but you add it manually on the address line of your browser, it will work as expected. The result redirects you to the Windows Live web site without any 401. Note that I've made some improvements to my source code. If you manually type the login URL on the address bar using the code as downloaded from CodePlex, you are much more likely to see some kind of NullReferenceException instead of a successful 302. But my point is that it will actually run your code.

The Final Verdict: Ye Not Guilty

So, then, this answers how to fix the problem, but doesn't identify the cause. Is this an issue with the .NET framework or maybe SharePoint itself? Well, that might be possible, but I thought it was unlikely given that these products have probably gotten some pretty thorough testing, especially compared to CKS and the WLA provider. But, I was on a mission. I wanted to make this work, and I had a clear path to explore, so there was no time to ponder this in depth.

What should've also crossed my mind at the time - but didn't - is that this issue might have been caused by code running in CKS itself. I ran into some other issues in the following days, but after everything blew over, I did some experiments to try and prove that CKS EBE itself was not at the heart of this particular problem. (Turns out I proved myself wrong.) To test this, I tried changing the settings for Secure System Pages in the CKS EBE Settings (a.k.a. Blog Settings).

There were two takeaways from this that finally explain this issue in black and white.

Lesson #1
The first is that just because you change your Blog Settings on the internal (Windows Authentication) site, does not mean they will automatically change on the public facing (FBA) site. While trying to make changes to the setting above, I learned that you need to make changes to Blog Settings manually to both sites. This is actually pretty cool, because it means you can select different themes for each and change some settings as appropriate. Also, it makes sense, since these blog settings are stored as a section in web.config for each site. But it is also a pain, especially if you have already configured FBA on the public site and you can't actually login to make settings changes.

Lesson #2
Second, I learned that everything I did from here on out is – at least partly – unnecessary. To work around this issue you simply need to turn Secure System Pages off. This will eliminate the problem with the login page having a query string. Of course, I happen to like this setting and want to use it on my public facing site, so I'll be working with this code to make it work properly with WLA.

Ever Deeper Down the Rabbit Hole

Now that I've revealed "whodunit" in this little mystery, let me jump back. Instead of finding the exact cause right away, I would spend the next two days trying to make the login page work correctly without the query string. I went through a lot of code changes to liveatuh-handler.cs in the attempt, and I learned a lot. Because this is not the end of the story, I plan to talk about these things just a bit before I'm done, but nobody will blame you if you skip all that and just get the code. [TODO: publish and link to code please]

So my first approach was to try and rewrite liveauth-handler.aspx so that it could just tell that you were going from Authenticate.aspx and redirect you to the Windows Live site automatically without being told via the query string. To some extent, this worked, but it took some messing around the find the right commands, and the HTTP_REFERER was not always what I expected it to be.

Here's a screen shot from my early code:

You can see at this point that I had already done some work to eliminate "Object Reference Not Set" exceptions. That's pretty typical of code written in a rush. You get it working to the extent that you need it to. Since you have other stuff to do, there isn't time to imagine every way in which it might go outside that corral, you move on. Unfortunately, it results in code that breaks easily, which it did for me many times.

You can see in these shots of the debugger as I was digging around for the HTTP_REFERER variable within the page Request object.

Its value would typically be something ending in "default.aspx" or "authenticate.aspx" whenever I was clicking through from the Sign In link. It would be easy enough to tell that the referrer was on the same server using a string comparison or RegEx, but fortunately the .NET framework has provided a couple of handy properties in the HttpRequest class that help to isolate the host name. These are Url and UrlReferer as seen below.

Interestingly, page redirects from the WLA site would have no referrer at all. I would've preferred something like "https://login.live.com/ppsecure/post.srf?appid=000000004400143A&alg=wsignin1.0..." Alas, no, they are just blank. This makes them indistinguishable from URLs entered on the address bar, and that made testing a nuisance.

Despite this, I was able eventually to muddle through. There were a number of setbacks, like this one:

This issue, or some other error, will happen when you have Secure System Pages turned on. (The exception message is my code and not part of CKS EBE or WLA, because I thought it would be helpful for other developers.) I did some experimentation to prove that when Secure System Pages is turned off, the new users will be automatically redirected to liveinfo.aspx as they should be. Also, the issue does not affect users who have already entered an email address in their Blog User Profile, because those users are typically redirected to a generic (unsecured) page such as default.aspx instead.

What's going on here is that Windows Live returns with a valid session ticket as an HTTP form post, but since the user does not yet exist in SharePoint or have any rights other than those granted to Live Authenticated Users, they get redirected from liveinfo.aspx to the liveauth-handler.aspx login page, probably by way of authenticate.aspx. (In the original source code from CodePlex, this would've forced their session to be logged out.) The redirect causes the contents of Request.Form to be lost, which is the means by which WindowsLiveLogin.ProcessLogin() method receives data from the Windows Live website. Even though you'd think that such an internal referral should have some kind of value in Request.UrlReferrer, its value is in fact null. The code, as I had written it at this point, failed because this condition is a contradiction. On the one hand it thinks it is supposed to process some kind of result from Windows Live, but that information has been dropped.

In a nutshell this means that any user who hasn't provided an email address is going to get some kind of error after they log in, and it is very likely that such an error will cause the authentication process to break down before all the cookies have been properly set. Looking at all this strange behavior, I have decided that the entire flow for the page needs to be streamlined and bulletproofed. (Though as of December I still haven't gotten around to it.) It's too convoluted and unreliable when conditions fall outside the norm. In the long run, the issue can be corrected entirely by fixing the code for BlogHttpModule.cs in the CKS.EBE solution.

But, let's talk a minute about the process by which I came to discover that this is what was going on, because it did not come easily.

To have results come back from the Windows Live site, and not have any form attached to them, was very confusing to me. I wanted to try and prove that the form was in fact coming back across the wire, and then being lost someplace else. To this end, I downloaded a very useful tool called EffeTech HTTP Sniffer which I have used on many passed projects to gain insight into what SharePoint is doing behind the scenes. It is my opinion that an HTTP Sniffer of some kind should be included on every SharePoint developer's installation checklist.

I was unable to get any meaningful data from the HTTP Sniffer though, which returned only a generic HTTP request and a GIF for the passport logo. Upon post-back from the Windlows Live server there was not showing up in the trace. So, I tried their EtherDetect product to see if I could figure it out. Here is an example of what came back.

Digging into these, I was able to determine that my server was opening a random port that connected to their server on port 443. Several tests concluded the port was random, and so I was unable to add it to the list of ports in the HTTP sniffer, and everything I saw in the Ethernet sniffer was of course encrypted. Unfortunately, this is a failing of the EffeTech HTTP Sniffer. The MSN Sniffer was totally useless for WLA. But, at least I was able to determine that there was some kind of data coming back.

Eventually, I was able to blunder into the solution of manually adding an email address to my entry in ProfileList, and that got me around the problem with redirection to viewinfo.aspx. This is not a good final solution, but I was able to move on to the next problem.

Okay, so now I could see that I had a form and I was able to step through code to the point where I could see that SetAuthCookie was executing. But, as far as I could tell, there was no cookie and no authentication within SharePoint going on at this point.

By this time, I may have been chasing foo-fighters. I had been a while in the weeds, and the default theme for CKS EBE provides no visual indication that you are signed into SharePoint as any particular user - something I have since changed in my own blog site as you can see at the top of this page. For this reason, I recommend that you create your own theme that makes use of the wssuc:Welcome control to tell you who is logged in. It could very well be that for some time I was actually successful at authenticating and did not know it, because Live Authenticated Users was not assigned any special rights. Note that even if you add this group to the Contributors, it will not automatically be able to create Blog Posts.

Another thing I tried was to remove the domain and path properties from my forms tag in web.config, but I have since put them back so I know they are not to blame in this case. I also tried changing the name of the form from "livelogin" to "LiveID", but I have also changed this back without any effect. For the time being if there were authentication issues around cookies, I have been unable to reproduce the problem.

Ultimate Solution: Fix Secure System Pages

Although I did eventually end up reverting to the use of a query string for the liveauth-handler.aspx page, I wanted to clean up the code somewhat anyway. I also implemented a fix for the BlogHttpHandler.cs that resolves many of the issues described above, and could probably be improved upon even more. Given time I would like to make the list of allowed system pages configurable from an XML file in the Feature (or maybe even web.config itself).

You can download the code here. I only provide the files in question, and I'll submit these issues to CodePlex as soon as I get the chance, but I wanted to make them available here for those experiencing similar problems. Enjoy! [TODO: publish code and provide link]