HomeASP Performing Web Authentication and Administ...
Performing Web Authentication and Administration with LDAP
Chapter 1: The Basic Login Chapter 2: Which Directory? (Root DSE Searches) Chapter 3:Add New User Chapter 4: General MaintenanceProviding a login interface for a website, as well as an administrator interface formaintaining a user dat ...
Providing a login interface for a website, as well as an administrator interface for maintaining a user database is an important feature for any serious website. I'll demonstrate in this text how easy it is to do this.
An easy and convenient way to deal with all of this information is with an LDAP server. There are many benefits of using an LDAP Directory over a database, but I won't get into that for now. In this document I will cover how to authenticate a user/password pair in ASP with your LDAP server, how to determine which directory a user is in (if your Directory Server contains more than one directory), how to add new users, as well as how to handle general maintenance of the users (additions, deletions, and modifications).
In order to accomplish all of this I'm going to use the IP*Works! LDAP component from /n software. For this document, I'm going to specifically use the ASP Edition of these components. There are many different editions to choose from - ie ASP.Net which would provide an event driven asynchronous interface.
First things first - we need a login form for our users! Here's a nice simple one:
Now, when the user clicks on the "Login" button, the form will submit to itself. We'll add some asp code so that if a post is detected, the authentication of the user will take place. First, we'll create the LDAP object (set ldap = Server.CreateObject("IPWorksASP.LDAP")). After that we'll perform a search for a UID that matches the loginname of the user. To do that, we'll need to point the LDAP object to the LDAP server, provide a base DN on which to perform the search (see DSE Information for more details), and set our search filter to search for this particular UID.
If Request("REQUEST_METHOD") = "POST" then
'create the ldap object
dim ldap
set ldap = Server.CreateObject("IPWorksASP.LDAP")
dim found 'flag variable for whether or not we
find the loginname on the server
ldap.Servername = "Server"
ldap.DN = "ou=People,dc=Server"
ldap.SearchFilter = "uid=" + Request("loginname")
found = false
ldap.Search
Now, the NextResult property of the LDAP component will attempt to read a response from the server. Be sure to set a timeout first so that if no response is available, you won't waste time expecting one. The value of the NextResult property will be 1 for search results and 0 for other responses (ie a response to an Add, Delete, or Modify method). In this case we are obviously expecting a search result, so we'll wait until the NextResult property is 1.
while ldap.NextResult = 1
found = true 'set found to true if we find any positive search results
wend
The above loop will allow you to set the found flag after a successful search result is obtained, signaling us that we have indeed found this UID in the directory. Now if we have found a possible match, we can see if the password he provided on the html form will successfully authenticate to the directory.
if found=true then
'try to authenicate
ldap.DN = "uid=" + Request("loginname") + ", ou=People, dc=Server"
ldap.password = Request("password")
ldap.Bind
if ldap.NextResult = 0 then
'NextResult will be zero if the server sends a bind result 'the result in this case will be either "OK", bound successfully 'or "Invalid Credentials", meaning the password does not match.
if ldap.ResultDescription = "[ok]" then
response.write "Success! You have been validated."
else 'login result was not "OK"
response.write "Invalid Login."
end if
end if
else 'found flag was false, we did not find the user in the directory
response.write "Invalid Login."
end if
end if 'end for the if requestmethod=post statement
Its possible for an LDAP server to contain more than one directory. For example, a directory for customer/client contacts, and a directory for employees. So if you want to have the same login interface for both of these groups of people, you might need a way to determine exactly which base DN's to perform your search against. Each directory on the server will have a unique base DN. For example, on our server, the customer/client contacts directory base DN is:
ou=People, dc=Server
The employee directory has a base DN of:
ou=Employees, dc=Server
If you don't know what these are - how can you determine them programmatically? This is one of the things that can be resolved by the root DSE search. DSE information is directory specific entry info. This is information that all LDAP servers will provide so that clients can have access to attributes of the server itself. Some of this information can be quite useful. For one example - each LDAP server can actually contain several different directories. One of the DSE Attributes is called "namingContexts", and this attribute is a list of base DN's (one for each directory) that you can access on this particular server. DSE Information will also tell you which versions of the LDAP protocol the server can understand.
A DSE search requires several attributes:
Blank DN
Search Filter of "objectClass=*"
Search Scope of "Base"
These properties can be easily assigned with the LDAP component, like so:
We'll use a similar method for obtaining the result from the server. First we'll wait for the NextResult property to = 1, signaling that the server is finished and has a search result.
While ldap.NextResult = 1
Response.Write("<b>Performed Root DSE Search:</b><br>")
Wend
Now the search result of a DSE search will not be like others - where you are searching for a particular DN. The only thing returned by this search will be attributes of the server, and these will arrive in the attribute property arrays of the LDAP component. Specifically, the ldap.AttrType() array will contain the type of each response attribute. The ldap.AttrValue() array will contain the corresponding values. AttrCount is the total number of attributes returned by the server. In this case, we are only interested in the namingContexts attributes, so that we can see exactly which base DN's we have on this server. Lets pick these out and write them.
Dim foundnamingcontexts
foundnamingcontexts = false
For i = 0 To LDAP.AttrCount - 1
'this line prints out ALL attributes
'Response.Write("ATTR " + ldap.AttrType(i) + " = " + ldap.AttrValue(i) + "<br>")
If ldap.AttrType(i) = "namingContexts" Then
foundnamingcontexts = true
Response.Write("namingContexts: " & ldap.AttrValue(i) & "<br>")
mybaseDN = ldap.AttrValue(i)
Elseif ldap.AttrType(i) = "" And foundnamingcontexts = true Then
Response.Write("namingContexts: " & ldap.AttrValue(i) & "<br>")
Else
foundnamingcontexts = false
End if
Next
This for loop becomes a little more complicated than one might imagine. The first instance of the namingContexts type in the attribute arrays is of type "namingContexts". But for subsequent attributes of the same type, which arrive one after the other, the server doesn't specify that type, but just leaves the type as empty string. In other words, in order, the server sent attributes like so:
So "dc=siroe, dc=com", "dc=Server", and "dc=Netscape, dc=com" are all namingContexts attributes, even though the second two have empty string as the type.
In the demo with this document, I'm just going to pick the first base DN here. You can include code on your own to either hard code this differently, or even allow users to select which "group" they belong to. For example: an option box specifying whether they are a customer, employee, or what. Also, you could even try their login ID against all of them.
Ok, so now we've got a working login page for our website. But what happens when someone new drops by and wants to join or create a login? You need to programmatically add them to the LDAP server so that they can authenticate themselves. As it turns out, this is quite easy.
The information that we'll need from the user is of course a UID (loginname) and a password. Just for demonstration, I'll also set a description attribute for the user. If you want other information - go for it. But keep in mind that the LDAP server allows only specific attribute types, and you'll need to stick with those. This shouldn't be a problem because there are tons defined: address, phone number, description, and many others for you to use. See your server documentation for a full list.
When the user submits this information, we'll need to setup the DN and attribute arrays for this new LDAP entry first.
Before you set the DN - you need to know what base DN to add this person to. This won't be the same base DN that you perform the search on (most of the time). For example, a common base DN for the search might have been simply "dc=Server". Most of the times, the directory "Server" will have a child named "People". So the base DN for adding an entry would be "ou=People, dc=Server". If you are unsure about this DN, please consult your server documentation, or browse the directory until you find the tree where you want to add the entry and find its DN. Once you have the DN (ie "ou=People, dc=Server") we'll want to modify it to create our new users dn. To do this, we just add their UID to the beginning of it. If our users loginname is "SJenkins", you can set the DN = "uid=SJenkins, ou=People, dc=Server".
Every LDAP entry is required to have a set of "objectClass" type attributes. For a person, these are:
type = objectClass, value = top
type = objectClass, value = Person
type = objectClass, value = organizationalPerson
type = objectClass, value = inetorgperson
So before we add this new DN to the server, we'll need to set its attributes. We do this using the ldap.AttrType() and AttrValue() arrays. Below we'll simply set a description, the UID and userPassword.
Voila! Now we have all of this new users attributes set up including his uid and password. We have his DN set. Now all thats left to do is Add him to the server. Thats the easiest part!
ldap.Add
SJenkins will now be able to login with his password via the method outlined in chapter 1.
Any administrator needs to have a method of manually adding, deleting, or modifying user accounts under their control. By using LDAP as an authentication and directory tool, you can of course perform general maintenance on these accounts by hand, in person, on the actual server itself. However, with this LDAP component, this could also be done via the same website. This would allow website administration to take place remotely.
As far as adding new accounts - we'll - we've already covered that. Deleting and modifying accounts are equally as simple.
In order to delete an account - all you need to do is set the DN for that account and use the Delete method.
Couldn't get much easier than that. But what if you don't want to delete the account - you just want to deactivate it. The purpose being you want to still have a record that this account exists, but you don't want the user to have login access any longer. To do this, you could use an attribute that specified account status. When the user attempts to login, check this attribute to verify that the user has login rights. You might use the description attribute for this. When we added SJenkins to our directory, we gave his description type attribute the value of "New Account". Now if we want to suspend this account, we could change this description attribute to "Suspended".
To do this we'll need to modify the existing attribute. The LDAP component includes a modify method for doing this. The modify method can perform different kinds of attribute modifications: Add attribute, Delete attribute, and Replace attribute. Since the description attribute already exists, we'll use the Replace choice. This is defined in the AttrModOp() array.
Here, we just have 1 attribute that we want to replace. So we'll set the AttrCount to 1, the zeroth (1st) element of the AttrType() array to the type we are looking for (description), the zeroth element of the AttrValue() array to the new value for this attribute, and the zeroth element of the AttrModOp() array to 2 (replace). Then just call the Modify method.
After this, if we examine the description attribute for SJenkins, it will have a value of "Suspended" instead of "New Account". If we wanted to delete/add the attribute type description of the value "Suspended", we would use the same method, except we would set AttrModOp() to 0/1 (Delete/Add) instead of 2 (Replace).
More Information
For information about the author, please contact lancer@nsoftware.com. For more information about IP*Works! or the LDAP component, please visit /n software.
/ 18 
Make SQL Queries over HTTP with XML with VS.NET
