LDAP Authorization useless, fcgi Authorization broken?

Discussion in 'Install/Configuration' started by System, Oct 15, 2005.

  1. System

    System New Member

    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?
  2. System

    System New Member

  3. mistwang

    mistwang LiteSpeed Staff

    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! :)
  4. System

    System New Member

    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.

    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.

    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.

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

    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.
    that makes senses and also explains why my girlfriend is so much younger than myself :p
  5. mistwang

    mistwang LiteSpeed Staff

    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.

Share This Page