EXT: LDAP Server Configuration¶

LDAP_SYNC¶

MAP_OBJECT¶

Other than with content objects in standard TypoScript you are not free to choose any given name for your MAP_OBJECTS. The name of the object must be a valid field name of the database table you want to sync to. In order for the LDAP_SYNC object to work you must at least provide one MAP_OBJECT corresponding to the field defined in the uniqueField parameter. Example:

FEusers = LDAP_SYNC
FEusers {
        ....
        uniqueField = username
        fields {
                username = MAP_OBJECT
                username {
                        attribute = sAMAccountName
                }
        }
        ...
}

LDAP_AUTH¶

The LDAP_AUTH object is needed by the ldap_auth extension to configure backend or frontend authentification

Single-Sign-On (SSO)¶

Often the application context in which authentification against a LDAP directory is needed is one where so-called Single-Sign-On functionality is wanted as well – in an intranet for example.

The connection of TYPO3 to a LDAP user directory for authentification is usually driven by a wish for having a single source where user data like passwords etc.. are being kept. A single source strategy does not entail a single-sign-on strategy. It just means that different systems (i.e. a workstation, TYPO3, ...) authenticate against the same source.

SSO takes the thing one step further by trying to let one system participate in the actual login the user has done in the context of another system to spare her or him another loginform. For a webapplication like TYPO3 this typically means that it tries to participate in the login the user has done on the workstation he or she is accessing the webapplication from.

Of course, there are certain limitation to that participation. A PHP application – or any other application for that part – can not just ask the workstation for the username and password the user has entered ealier and use that to authenticate the user once more. There should be no way for the webapplication to get the password. However, depending on the context there are numerous ways for the webapplication to gain access to the username under which the user has done a successful login on the machine. If the webapplication is provided with a username from a trusted source it can then go on to instantiate a user session for that username under the assumption that this user is already authenticated.

Let's have a look at some scenarios:

Active Directory

Prerequisites:

• Apache 1.3 with Kerberos module integrated into ADS Kerberos environment
• Internet Explorer as agent with special intranet security settings

Result:

The Apache Kerberos module sets the PHP variable $_SERVER['REMOTE_USER'] with the login username of the user authenticated on the requesting workstation.

NetBios

There are simple libraries for PHP which are able to retrieve the username of the active login on a workstation if the NetBios protocol is enabled.

Novell eDirectory

Some versions of the Novell eDirectory save the IP of a user's workstation with the user record within the LDAP directory. It is therefore possible to write a function which queries the LDAP directory for the IP and retrieve the username on this basis.

All three scenarios have the result for the webapplication wanting to implement SSO functionality. They provide the webapplication with a way to access the username.

In the context ot the authentification service this leads us to the following requirement for the service application:

• The service must be active even if there is no username or password given
• There must be a way to “ask” trusted sources for a username.
• As there are many possible ways to get to a username the system must provide a simple API for various methods of username retrieval.
• There must at least be two ways of authenticating a username. With password and without password.

How are these requirements met by the ldap_auth – ldap_server application system?

The ldap_auth extension gives you the possibility to configure the authentification mother class to always include authentification services if there is no valid user session found. Please have a look at the documentation of auth services found in the extension cc_sv_auth for details and the extension ldap_auth for a working example. This means that the service is included even if there is no username and password explicitly given through form input.

The configuration of the LDAP_AUTH object provides you with an interface to define your custom functions or class methods for retrieving a username. Use the LDAP_AUTH parameter SSO for this purpose. SSO can contain a numerical array which holds one or more definitions for functions which should retrieve username data. Example:

SSO = 1
SSO.10.userFunc = PATH_TO_FILE:CLASSNAME->METHODNAME
SSO.20.userFunc = PATH_TO_OTHER_FILE:OTHER_CLASSNAME->OTHER_METHODNAME

What you do inside your method is of no importance to the authentification service. The method could just be an interface for an elaborate external application reinventing the wheel – it really does not matter. What matters though, is that the methods returns an array as seen below :

array (
        'username' => 'THE USERNAME YOUR METHODS HAVE FOUND',
        'authenticated' => '1'
)

Of course, your application should only return this array if it is sure that whatever username was found is thoroughly authenticated. The only other requirement for the service being able to instantiate a user session for under this username is that this username is actually found in the LDAP directory.