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 acco
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
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
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.
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.
The way this works in our system:
This way the user can reuse their windows domain authentication inside our app.
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.
Here is one useful bit of software that allows LDAP directories to be accessed over the web, using JSON-RPC: Json2Ldap