One of the many ways to achieve LDAP SSO using Delivery Server 10.1

Have you ever tried to Single Sign-On LDAP users into Delivery Server projects? Last week I was looking for a quick and easy method, with special assistance from Tim Davis (and thank you!), here I am documenting the steps to achieve this.

My solution can be explained in the simple diagram below:

Solution Architecture

As you can read from the diagram, I am using .NET to read the user name, format my own digest string, and then include hash value as one of the request parameters in the URL before getting redirected to Delivery Server by ISAPI. Once the request has traveled to Delivery Server, I can then use the username provided in the URL, compute and compare the hash values; if the hash values match then I can use dynament code to login the user automatically using the trusted mode.

Step 1 – writing  .NET code
This one is easy, very straight forward; a few variables, one function, one redirect.

FUNCTION_PAGELOAD

At the end of the Page_Load, I redirect the user request to a virtual directory I made up with the same name as the Delivery Server project name (just to make the URL user friendly).

Read more of this post

Troubleshooting Common Search with Delivery Server [Best Practice Project]

I went through the post blogged by Danny Baggs over and over again for about more than 10 times while setting up my Common Search server but it was just not working! There is nothing more frustrating than having the search working in Livelink but not in Delivery Server. I am new to the whole LiveLink interface thing and that didn’t help me either. If you are on the same boat and are having similar issues, I hope this post will assist a little.

From reading Danny’s post, we all know that we need to set up a shared folder and a Delivery Server connector to communicate with Common Search server. Here is the summary of what I’ve concluded after my 3 day’s tough time in regarding to how the integration works.

Delivery Server creates xml files which contain all the information about pages and project content, those files are stored under the shared folder for the Common Search Server to process; therefore, both servers need permission to write and read contents in this shared folder. The Common Search Server then indexes the files created by Delivery Server, creates a collection and sets up a search scope for each project . When a search query is performed, Delivery Server sends a request to the Common Search Server, the search query gets executed, and returned to the Delivery Server Server in the XML file format.

Easy, yeah?

So, here we set up the Delivery Server Connector, and I want to use my own Common Search user but not the Admin Account.

First tip, make sure the user has the “System Administration Rights“. This can be configured in the Common Search Interface. Read more of this post

SeeUnity’s DM Integration for SharePoint – Overview

Recently I got my hands on some of the SeeUnity’s powerful Integration Components. SeeUnity has two components designed for SharePoint, the Enterprise Integration and the Archiving and Distribution Services. The first one allows users to access or push eDocs documents via the common SharePoint Interface, and the later one allows documents to be synchronized or  linked (manually or automatically) between SharePoint and external repositories based on customized rules and field mappings.

There are many functionalities provided by these two components, but doesn’t matter how many you are configuring, there are two things need to be understood before getting your hands dirty.

  1. Understand the number of applications required to be installed and
  2. Decide where they should be installed.

It sounds easy, but for me this was the most difficult part. In most environment, there are at least 2 servers involved (given that the chance of having both the SharePoint Server and DM Server on the same box is extremely low); the DM server and the SharePoint Server. To make it even more complicated, some of the components can even be installed on a dedicated SeeUnity Server for performance optimization.

The SeeUnity’s documentations are fairly well documented, but not all the scenarios can be covered; and the fact that it is so flexible, it does add some complexity to the installation process.

The core applications for the integration are:

  • Core Integration Services

Read more of this post