Litespeed LDAP vs. mod_auth_ldap in Apache

[edlott]

Please confirm the following:

1) Apache supports "ldap" and "ldaps" whereas Litespeed only supports "ldap".

2) Apache uses the following authentication process:

1a> Bind to LDAP server with info configured in AuthLDAPBindDN/AuthLDAPBindPassword.
1b> Search for matching ldap record based on AuthLDAPURL and other attributes.
1c> Bind to LDAP again using the record found in 1b> and the password supplied by the user.

Litespeed appears to do the following:

2a> Bind to LDAP server with info configured in LDAP Bind DN/LDAP Bind Password
2b> Search for matching ldap record based on User DB Location
2c> Compare the 'userPassword' attribute of the record fetched in 2b with the password the user entered.

PROBLEMS:

1) We currently use "ldaps" to communicate with an ldap server that's on a different box from the webserver.
2) Per contract requirements, we need to 'lockout' a user login if invalid login attempts exceed a certain number. The apache process (1c) hits our ldap server with every login attempt - our ldap server will lock-out the account when a maximum number of bad logins are submitted. You're matching process (2c) won't be able to register bad login activity with our master ldap server.

If I can't replicate the apache process for working with LDAP, is it possible to write a custom URL/authorization program with Litespeed where I can do the LDAP magic myself (i.e. using Perl libraries)?

Thanks in advance,
Ed

 

[mistwang]

You can write a FCGI authorizer using LDAP in perl.

 

[edlott]

Do you have a simple example of a perl script that acts as a FCGI authorizer? What values should I be looking at in $ENV? What do I have to configure to get a web-browser login dialog to display to the user?

Thanks in advance,
Ed

 

[mistwang]

no sample here, please check the fastcgi web site, it is standard. Basically you need to define a FCGI authorizer external app in LSWS.

 

[edlott]

Please confirm the following:

1) If you have a context setup as follows:

Realm: (empty)
Authentication Name: (empty or non-empty)
Authorizer: [VHost Level]: (program)

...then the following happens:

1a) The authorization program is invoked without any REMOTE_USER or REMOTE_PASSWORD fields.
1b) If the program returns a status other than '200', a blank page is displayed.

This functions like FastCgiAuthorizer in apache's mod_fcgi.

2) If you setup a context as follows:

Realm: (file-database realm)
Authentication Name: (empty or non-empty)
Authorizer: [VHost Level]: (program)

...then the following happens:

2a) An authentication dialog is displayed to the user until they enter credentials that match the database file.
2b) The authorization program is invoked. REMOTE_USER is set to the name of the authenticated user. The REMOTE_PASSWORD field is NOT sent. If the program returns a status other than '200', a blank page is displayed.

This functions like FastCgiAuthorizer in apache's mod_fcgi.

3) There is no way to bring up a dialog and pass the contents to a fastcgi. Litespeed has no support for FastCgiAuthenticator in apache's mod_fcgi.

CONCLUSION:

If you want to AUTHENTICATE uses at the web-server level, your only options are Litespeed's password files or LDAP implementation. If you want to use a custom authentication procedure, you have to use Litespeed as a reverse proxy in front of apache, which supports this functionality.

SUGGESTION:

Create a new Realm type called 'FastCGI' (in addition to 'Password File' and 'LDAP'). When this is selected in a context, the webserver displays a login dialog and passes the REMOTE_USER and REMOTE_PASSWORD environment variables to the fastcgi. In this instance, the cgi works like a FastCgiAuthenticator in apache's mod_fastcgi.