PKI and sponsorship with SharePoint

We've been working on some interesting solutions with PKI (public key infrastructure) and SharePoint sites. I can't go into a lot of detail now, but in a nutshell the system:

• Accepts the users PKI identity certificate


• Checks the status of the user's account


• Logs the user into Active Directory without requiring a password


• Forwards the user to the SharePoint site


• The user can access and contribute within the site as a regular SharePoint user

We also included some nifty certificate type checking, and certain users are required to fill out a sponsorship form and getting approved before they are allowed to access the site.

I'll try to put some details of how we accomplished this up at some point. Suffice it to say, it was a long road and many people helped along the way.

Has anyone out there integrated PKI with SharePoint? I'm pretty sure we're not the only ones doing it, so I'm curious how others have accomplished this.

Workaround for opening Office documents as read-only in SharePoint

In an earlier post, I ranted how opening Office documents (Word, Excel, PowerPoint) from SharePoint is a pain when you are using SharePoint from a different domain than your computer is logged in to. We finally found a workaround, which now seems obvious. Here's a review of the situation:

If your Windows machine logs into Active Directory domain "Homer," but the SharePoint site you access is on the domain "Lois" in a different location, you have to deal with login prompts instead of a streamlined integrated login. This is expected behavior.

In addition, Word, Excel, and PowerPoint documents opened from SharePoint need to authenticate the user as well, because the documents are actually opened from the web server, not the local browser cache. This is also intended functionality: the idea is that the user can edit the files and save them back to the server directly from Word, Excel, or PowerPoint. The user must type their username and password when each separate Office application is opened via the link for the document in Internet Explorer. Usually this is not a big deal.

However, opening documents from a SharePoint site in Internet Explorer is sometimes impossible when a third-party single-sign-on system is in place and the user doesn't actually have the Active Directory username and password handy. If the SSO doesn't know how to handle Office applications, it's impossible to open the files at all because they get stuck at the SSO login process. A workaround is to have users right-click the documents in SharePoint and "Save as," but chances are users would not get the message or forget.

So we finally came up with a workaround while we wait for a permanent solution via the SSO: Convert all Office documents to Adobe PDF. For documents that need to be available in the native Office format (.doc, .xls, .ppt, .vsd, etc.), compress them as .zip files. Use the .pdf and .zip files in the document libraries instead of native Office files.

This can work well for sites where SharePoint isn't being used for document collaboration, or where collaboration doesn't rely heavily on document editing. As far as I know, there's no other way around this problem other than converting the documents to non-Office formats or using a browser like Firefox, which doesn't try to open Office documents for editing from the web server.

We will figure out a permanent solution, but for the meantime the workaround will suffice.