Integrating WSS 3.0 Document Library into an existing asp.net application. Setting up the authentication.

If you search around the net, you’ll most probably find a lot of articles discussing how to create windows sharepoint services (WSS) modules or even how to install WSS on top of existing web site. In my case, I have to create a document management system in an existing asp.net application. In order to do so, I will be using the office integration that is provided by the document library of WSS and will be writing custom forms to handle the rest of the gui.

My asp.net application uses a customasp.net membership provider in order to authenticate users. So, my first idea was to enable Form Based Authentication (FBA) on WSS and setup the custom membership provider to handle the requests. Well, although this worked concerning the security aspects of the integration, the user had to login once more in WSS whenever he was requesting something from sharepoint and moreover, the office integration of the document library didn’t work well. To be more precise, whenever the user requested a document from the sharepoint server, word fired up and tried to open the specified document. The problem is that word doesn’t have the browser’s authentication cookie, thus the resource is out of reach and sharepoint redirected to the login screen. Having searched the net, I found that there was an update for office 2007 that would make office FBA agnostic but my clients had older versions of office and I couldn’t find anything for them. Moreover, I have office 2010 which would load the authentication form and display it to me as the requested document.

So I had to solve two problems; single sign in for both my asp.net application and the sharepoint services, and make office integration work with any version of office. The first problem can be easily solved if you create an encrypted authentication cookie that is available to both the asp.net application and WSS. The second problem can be solved if you make that cookie persistent, thus making it available to the whole system and not just the browser that made the authentication request.

I have already posted another blog post on how to enable forms authentication sharing across asp.net applications which partially solves the first problem. In the case of WSS you’ll have to note a few things.

First and foremost, the default configuration in the WSS site (defined in the web.config that usually resides in C:\Inetpub\wwwroot\wss\VirtualDirectories\<PortNumber>\) sets both the validationKey and decryptionKey to something like the following:

<machineKey validationKey="C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE" decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F" validation="SHA1" />

In that case you’ll have to copy this line and add it in your asp.net application’ web.config. That way, both applications will be able to verify the validity of the generated authentication cookie.

You’ll also have to set the timeout property of the configuration\system.web\authentication\forms node in the web.config to something high enough (30 or even more) in order to avoid any cookie expiration while working on an office document. If the cookie expires, the user will not be able to save his work and you’ll end up receiving technical support calls… Be advised that you’ll have to set the same timeout on all asp.net applications because otherwise the cookie is expected to expire in the shortest timeout specified among the asp.net applications.

Another thing we’ll have to take care of is the authentication process on sharepoint services. We shall not use the build in authentication form. Rather than that, we will be implementing a custom authentication HttpModule which will be redirecting any unauthenticated request to the asp.net application that we already have. In order to see how this is done, you may check my other blog post named “redirecting any unauthenticated requests to a login form located on another asp.net application”.

One final thing to do is to setup the same membership provider on both the asp.net website that will be authenticating the requests and the windows sharepoint services. As for the WSS, you should probably configure both the website and the management website (installed by default in port 2562) if you would like to manage the permission on the document library through the management site.

Hope this article helps a bit…