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).

Step 2 – Configure the lovely ISAPI

As many of you know, ISAPI is used to redirect traffic from IIS to Apache. Depending on the complexity of your project, redirect rules need to be defined in the ISAPI config file. I am not going into too much details about setting this up because there are many materials out there you can ask Mr. GOOGLE for.

IIS_JAKARTA

Windows authentication is definitely required here.

IIS_WINDOWSAUTHENTICATION

A Quick Overview at where we are at so far

We have two parameters in the request variable, one is the hash value produced by my function in .NET, and the other one is the user id in clear text. We now need to confirm that the hash value is correct; since MD5 is a hash value and can’t be reverted back to it’s original string, we need to produce our own hash value using dynament code and compare the values that way.  In order to get the hash value using MD5, a validation rule needs to be set up in Delivery Server, and this is what we will do in the step 3.

Step 3 – Set up Validation Rule on Delivery Server

Delivery Server allows customized rules to be defined via Admin Console.

Validation Rule

In my dummy project, I created a rule using GetDigest with MD5 (SHA is also available)

Validation Rule

Validation Rule

Step 4 – Dynaments

Now we have the validation rule ready, we can start developing our dynament code.

1. Format the digest string

hashvalue

2. Read Token Value

I had some problems with the value being cached during testing but not appearing in the object cache listing; this is just a workaround for the value to be read on every page refresh.

XML DYNAMENT GET TOKEN VALUE

 3. Compare hash values

Here is where we compare the hash values and decide whether we can automatically log-in the user. This algorithm can be extended to check whether the user is already logged on, and included in your normal login XML.

DYNAMENT - COMPARE VALUEs

That is it! I believe there are other ways to achieve the same result, so please feel free to provide some feedback and your experience 🙂

Advertisements

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

  1. Danny Baggs says:

    Thanks for documenting Shelly.

    Dan

  2. Tim Davis says:

    You may consider HTTP Header for transfer of data vs query string. Just that much harder to find your digest info

    rde-rd:httpHeader-{Http-Protocol-Header-Name}
    All fields of the HttpServletRequests are read and transferred to the
    source=”request” with the name prefix “rde-rd:httpHeader-“. Now they are
    available in the Attribute DynaMent.

    • Shelly Mao says:

      Thanks and that sounds like a great idea!

      However, I ran into an issue when trying to implement this – where

      header variables set in .NET don’t get carried over to the new page request when using Response.Redirect; while Server.Transfer does carry the header values over but doesn’t trigger ISAPI redirect since the URL stays the same… (frustrating)

      This could possibly done in other languages other than .NET…

      Open to more ideas and feedback here 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: