How to build LDAP integration for my web app?

Question

My company develops and sells a SaaS application that has hundreds of customers. Some of our customers have asked us to support LDAP integration for authenticating user accounts against their existing systems instead of having to create another login account for each of their employees. Seems like this is referred to as Single Sign On (SSO) in many places? Naturally our system already has a mechanism for maintaining user account profiles and authenticating those user accounts from our login page.

We're a bit ignorant about LDAP and are confused about a few things. Please excuse the possible use of wrong terminology (remember, we're a little ignorant about this).

We think we understand the basics of how this might work:

• Our customer configures their account to "turn on" the "remote authentication" feature for their account. They provide the remote URL that will authenticate their users.
• Users come to our login page and attempt a login using their username and password provided by their company's LDAP system.
• Our login page will securely forward the login credentials (presumably encrypted and hashed in some agreed upon format) to the "remote authentication" URL provided by our customer.
• The customer's script will authenticate the user and then redirect them back to our site with the "authentication status".
• Our page will analyze the "authentication status" and either accept the user as logged in or not.

Assuming the above information is even semi-correct, we'll still need each user to have an account in our system. Won't we need some way to synchronize our user account profiles with the user profiles in the LDAP directory? Is this simply an "external ID" that references the user's ID in the LDAP system? Would it then be required that the customer's "remote authentication" script must provide that ID to our system so we know which user account in our system to associate the login with?

What are we missing?

BTW, our platform is IIS, ASP.Net 2.0, and SQL Server 2005.

Answer 1

There are several options. If you really mean LDAP, as opposed to just Active Directory, I would probably look at using System.DirectoryServices.Protocols to perform an LDAP bind using the supplied credentials via a secure channel.

Strictly, this isn't Single Sign-On. SSO means only having to submit your creds once when you first log on. This is simply reducing complexity for the users by only having a single ID. Usually, for Windows clients in an enterprise environment with a mixture of platforms and technologies, SSO is achieved by a client added to the desktop which manages authentication to various systems. In an MS-only environment, you might achieve SSO if all of your web apps are on IIS, you use IE and use Integrated Windows Authentication, impersonation and all of that stuff.

You could consider auto-enrolling an authenticated user into your system, unless you require profile-type data to be preconfigured. If you do require pre-configuration of users, you could consider regularly importing (all, or a filtered subset of) users from the LDAP directory and having them in a not-configured state, such that the admins select from an existing list of not-configured users rather than typing in IDs. Otherwise, you risk your admins typing in the wrong user ID and having mismatches.

You could provide an API such that Identity and Access Management solutions (given your Microsoft slant, see ILM2 007 as one example) can integrate with your system and do all of the user account management for you.

Answer 2

The way this works in our system:

• When a user navigates to the web app, the REMOTE_USER server variable is assumed to be the user token
• The login code connects to the ldap directory with a search-specific account
• The login code looks for an ldap account that "matches" the REMOTE_USER
• The login code then tries to match that account with an account in our system
• If matching is possible all the way through, assume the user logged in as the matched account, continue normally

This way the user can reuse their windows domain authentication inside our app.

Answer 3

As always remember to validate the authentication test to be sure that the password sent is not blank.

A bind with a user name and no password is considered an Anonymous bind, according to the standard, and looks like it has succeeded! When in fact, it really did not.

This is an issue for the application to handle, since the LDAP server is just following the standard, an annoying standard, but a standard nonetheless.

Answer 4

Here is one useful bit of software that allows LDAP directories to be accessed over the web, using JSON-RPC: Json2Ldap

Answer 5

Perhaps consider Authentication Vs Authorisation

Authentication - which user is this? Authorisation - who should be able to use the application, specified users, groups?

Currently you are implying authorisation through authentication because only those who are registered to your app are allowed to use it.

If you use a directory instead of your custom datastore then

• use the directory connection method to authenticate the user
• you (may) get authentication for free - the user is known to windows, windows can identify to iis and sqlserver, maybe no need to ask the user who they are.
• you will know of more users than have authorisation and need to apply restrictions - limit connections to a particular group.
• could store user data in the directory, rather than with your app data in the sql server.

If your users really want generic LDAP, then you want to look into (C)ldap_connect, ldap_bind_s (C#) LDAPConnection System.DirectoryServices.Protocols

Or again back to AD this Demystified .Net App single sign on might help

Answer 6

You need to decide how you plan to link an LDAP user to an account within your application.

For example, you could require that the username within the LDAP system match the username within your app, or you could require that someone explicitly specify an LDAP username within each user account in your app.

Once you've got that link figured out, you can simply execute an LDAP bind to test user credentials.