LDAP Authorization useless, fcgi Authorization broken?

System · Oct 15, 2005

I would like to use LDAP Authorization with my instance of lsws-2.1.2-std-i386-linux on x86 gentoo with a 2.6.13-ck7 kernel against some version of openldap configured for no read access to the crypted password. Having no access to the ldap servers' root password rules out lsws buildin support for ldap authentcation. Why don't you support "real" authentication, so that no special priviledges are needed? Why does lsws still open a connection to the ldap server even though no ldap using realm is configured?

Because lsws ldap auth couldn't work, I thought about using a fcgi perl app in the authorizer role. I saved the following perl script for testing at /opt/lsws/DEFAULT/fcgi-bin/ldap.fcgi and did chmod +x on it.

Code:

#!/usr/bin/perl

use FCGI;

while (FCGI::accept >= 0)
{
    if( $ENV{'REMOTE_USER'  } eq "foo" &&
        $ENV{'REMOTE_PASSWD'} eq "bar"  )
    {
        print( "Status: 200\n\n" );
    }
    else
    {
        print( "Status: 401\n\n" );
        print( "WWW-Authenticate: basic realm=\"foo\"\n\n" );
    }
}

__END__

I created a new fcgi authorizer in my vhost settings like this:

Code:

Name	LDAP Auth	
Address	uds://tmp/lshttpd/ldapauth.sock	
Max Connections	3	
Environment		
Initial Request Timeout (secs)	60	
Retry Timeout (secs)	0	
Response Bufferring	No	
Auto Start	Yes	
Command	/opt/lsws/DEFAULT/fcgi-bin/ldap.fcgi	
Back Log	20	
Instances	3	
Priority	0

I switched to the vhost security page and wondered why fcgi authorizers can not be used to create a realm. Does that ultimatly mean, that under no circumstances whatever so I can use an fcgi authorizer to protect /awstats because it only allows to setup a realm? Why are realms and authorizers treatet differently anyway? It looks like a bad design decision to me, that should be fixed as fast as possible.

Consulting the manual I finally found the proper solution. I created a new static context inside my vhost settings like so:

Code:

URI	/edit	
Location	/opt/lsws/DEFAULT/edit	
Accessible	Yes
Authentication Name	LDAP Auth
Authorizer	[VHost Level]: LDAP Auth	
Add Default Charset	Off

The other settings were set to N/A. I put a bogus index.html inside /opt/lsws/DEFAULT/edit. After setting the log level to high and switching debug on, I restarted the server.

Accessing /edit/index.html showed the ldap file without even asking for authentication. The error.log made no indication that fcgi is even tried:

Code:

2005-10-15 20:43:41.934 [DEBUG] [*:80] 1 connections accepted!
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0] HttpIOLink::handleEvents() events=1!
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0] HttpConnection::onReadEx(), state: 0!
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0] readToHeaderBuf(). 
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0] Read from client: 416
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0] processHeader() return 0, header state: 3. 
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0#Example] New request: 
        Method=[GET], URI=[/edit/index.html],
        QueryString=[]
        Content Length=0
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0#Example] Find context with URI: [/edit/], location: [/opt/lsws/DEFAULT/edit/]
2005-10-15 20:43:42.057 [DEBUG] [192.168.3.1:59511-0#Example] processContextPath() return 0
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-0#Example] readyCacheData() return 0
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-0#Example] Written to client: 213
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-0#Example] m_pHandler->onWrite() return 0
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-0#Example] HttpConnection::flush()!
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-0#Example] HttpConnection::nextRequest()!
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-1] processNewReq() return 0. 
2005-10-15 20:43:42.058 [DEBUG] [192.168.3.1:59511-1] readToHeaderBuf() return 0.

Did I miss something in the manual? Why doesn't it even try to use the fcgi authorizer? How can I fix my misconfiguration?

System · Oct 17, 2005

:cry:

mistwang · Oct 17, 2005

OK, got to answer the long post.

The reason we do LDAP this way because it will give the best performance, otherwise, LSWS need to make a new connection to LDAP server for every request, and OpenLDAP always use blocking mode for connect(), that's why we made a connection in advance.
I think Apache's mod_auth_ldap works in the similar manner. ;-)

For the authorizer, it is a bug in authorizer configuration handling, should be fixed in 2.1.3.

Your example authorizer script does not work though, two issues, one is "REMOTE_USER" and "REMOTE_PASSWD" will not be set by LSWS, as LSWS does not handle the authentication, so you need to decode them from $ENV{"HTTP_AUTHORIZATION"}, second issue is that there should be only one '\n' at the end of

Code:

print( "Status: 401\n\n" );

You are pretty good at picking up new stuff!

System · Oct 18, 2005

mistwang said:

and the worst security. write access to the database used for authorization for our whole department for anyone that compromises our closed-source webserver does not sound much fun to me.

mistwang said:

why would anyway want to use a lame static openldap connection, when you can use a supercool thread with dynamic connections instead totally solving the problem of blocking calls? besides the authorization needs only be done once per user and our local ldap server is pretty fast indeed.

also if performance is the main concern then an unneeded network connection is never a good choice. pushing the password hashes via a cron job from the ldap server to the webserver is easy to do, more secure and a whole magnitude faster. updating once a day is often more than enough. maybe after proper preprocessing even lsws will accept them inside a normal password file.

mistwang said:

never used it. lighttpd claiming to be fast and lightweight as well supports "true" auth, but I will need to stick to the perl instead. it is much more flexible and can also extract additonal user information from the database like user privileges.

mistwang said:

hopefully, but as you have no release date set I will stick to lighttpd now.

mistwang said:

Your example authorizer script does not work though, two issues, one is "REMOTE_USER" and "REMOTE_PASSWD" will not be set by LSWS, as LSWS does not handle the authentication, so you need to decode them from $ENV{"HTTP_AUTHORIZATION"}, second issue is that there should be only one '\n' at the end of

Code:

print( "Status: 401\n\n" );

it is not really my script anyway. I copied it for testing from http://support.zeus.com/doc/examples/fastcgi/auth-simple.html

looks like zeus also only supports "fast" ldap.

mistwang said:

that makes senses and also explains why my girlfriend is so much younger than myself

mistwang · Oct 18, 2005

Read access is sufficient, we don't think anyone should grant write access to a user role like that.

That's a design chooice, we'd like to stick with single thread with event driven I/O.

That's probably true in some environment, it is not a bad idea to do something like that, and an end user can implement something like that by themself, I don't think we need to implement it as a commonly used standard feature.

:shock: I hope you did not refer to its LDAP support. As we knew that all of their LDAP accesses are in synchornized mode, it is pretty scary in a single thread even-driven application.

It has been released it on our website yesterday before I replied your post, we just did not turn on our auto-update engine yet.

LDAP Authorization useless, fcgi Authorization broken?

System

Member

System

Member

mistwang

LiteSpeed Staff

System

Member

mistwang

LiteSpeed Staff