[Typo3-dev] LDAP System Extensions

Daniel Thomas dev at dpool.net
Wed Nov 17 19:33:20 CET 2004 

Hi all,

as you have probably noticed the topic authentification against LDAP 
directories was part of the possible feature list Kasper proposed for 
the next release of TYPO3. I have opted to lead the discussion towards 
a standard solution for this area because together with René Fritz we 
have already developed a functional LDAP authentification system which 
meets most of the requirements we could come up with. I would very much 
like to have this system broadly tested and disputed and would be 
willing to develop this further within the next 6 weeks in order to 
have a definite solution in beta phase for the snowboard tour.

And this is how I would like to do it. As an incentive I will sketch 
the basic ideas of our system in this email. I will do this in stating 
the goals which we set ourselves and then outline the way things are 
implemented.

I would like to spur several reactions to this email (ideally in this 
order):
- Feedback to the list of requirements: Additional requirements, 
priorisation ...
- Many people testing the system. (It is available for testing for 
everyone. Just look for René's cc_sv_auth extension and a collection of 
extensions with keys ldap_*)
- Detailed feedback/criticism on how things are handled in the system. 
Presentation and discussion of alternatives, if any.
- Offers to participate in the production of the collaboratively 
conceived solution, if any.

I would like to get back to Kasper in about three weeks from now in 
order to discuss changes needed in the core to support the 
authentification system. If setting a date helps I would like to finish 
discussion on the matter on friday the 10. of December. From then on 
this leaves us a sporty three weeks including christmas to produce a 
beta version.



1. Requirements
* Co-existence of LDAP authentification and standard TYPO3 
authentification - or any other possible auth mode.
* Possibility to define different LDAP server for different sites in 
one TYPO3 installation
* Possibility to define more than one LDAP server for one site in a 
TYPO3 installation in order to have fall-back solutions
* Support for any possible LDAP server type
* Possibility to deal with any possible LDAP schema
* Possibility to freely configure necessary data-mapping (LDAP record - 
TYPO3 record) during authentification including automatic assignation 
of group membership
* Design of a configuration system for data-mapping which is not only 
useable during authentification but also for importing any data from 
the LDAP server into any database table in TYPO3
* Hooks for Single-Sign-On
* Intergration with authorisation management of the LDAP server
* Possibilty to retrieve data from the LDAP server via the command line
* Introduce a bit of LDAP functionality into TYPO3


2. The LDAP extension system - A quick overview
The LDAP authentification system is implemented as an Auth Service. The 
actual service extension is the ldap_auth extension. However it is 
integrated into a series of other extensions. Please have a look at
http://dpool.net/index.php?id=829
for a diagramme. It is not very systemtic. Yet I hope it illustrates 
why there is more than one extension.

What are the single extensions good for?
ldap_lib
Contains a class developed by someone else and modified by us. It can 
be instantiated as an object in other extensions to get data from a 
LDAP directory rather like the $GLOBALS['TYPO3_DB'] object.

ldap_server
This extension provides a backend interface to enter configuration for 
LDAP directories you want to use in an application. Configurations are 
entered as records in the separate database table tx_ldapserver. A 
configuration comprises necessary parameters like servername, port, 
servertype, user, password ... It also comprises a way to freely 
configure the datatransfer between the LDAP directory and the TYPO3 
database.
What is meant by that?
Now during authentification we have to make sure that after the user 
has been authenticated the TYPO3 system finds a fe_users or be_users 
record in its own database to bind the session to. This means that the 
service might be forced to enter a record in one of the user tables. In 
a configuration we can define which attributes of the LDAP record 
belonging to the user should go into which database field of the user 
table in TYPO3. The nice thing about the system is that the same 
configuration mechanism can be used to configure the behaviour of the 
ldap_sync extension. This extension is not connected to 
authentification at all. It operates on the LDAP configuration as well 
and imports data from the LDAP directory according to the instructions 
found there. An example for a configuration:
###
test = LDAP_SYNC
test {
	table = tt_address
	pid = 20
	indentField = name
	dn = CN=one, CN=de
	filter = (&(objectClass=person))
	fields {
		name = MAP_OBJECT
		name.attribute = sAMAccountName
		name.userFunc = tx_test->test
	}
}
###
Now this would cause the ldap_sync Backend Module to import all LDAP 
records of the objectClass person found under the node one.de of the 
LDAP tree into the tt_address table. Records would be put on pid 20 and 
the only value written into a tt_address field would be the value of 
the attribute sAMAccountName into the field name. Before the value of 
the attribute sAMAcountName is entered into the field it would be 
processed by the method test of the class tx_test.

The ldap_server extension also provides a class which implements the 
application logic necessary to perform the operations implicit in this 
configuration.

ldap_auth
Does nothing but to authentify a user under specific credentials using 
the tx_ldaplib object, transfer data to one of the user tables using 
the tx_ldapserver object and signals back to the authentification 
parent class whether authentification was successful.

ldap_sync
Gets a series of LDAP_SYNC objects from the LDAP server configuration, 
uses the tx_ldaplib object to query the LDAP directory for the records 
and uses the tx_ldapserver object to transfer these to a given table.


3. How are the requirements met? (in same order as above)

* The first point - Co-existence - is not a feature of the LDAP 
authentification system but of the Authentification Service System 
designed by René on top of the general service system. I will not go 
into detail about this system here. However, I do think that it is a 
very good architecture providing programmers to use a clearly defined 
API in order to implement custom authentification schemes. If nobody 
comes up with a better solution for Co-existance I opt for taking this 
path in connection with LDAP authentification.

* The ldap_auth service uses the general record storage page concept to 
determine which LDAP server configuration to chose under a given page 
request. For different parts of the page tree you can then define 
differen LDAP server configurations.

* Within each of the general record storage pages you can define more 
one LDAP server configuration. The system will loop through every entry 
and use the first server it could connect to.

* I don't know about every possible LDAP server type. Yet tests have 
been made with Active Directory and Novell eDirectory. NT and Open LDAP 
should be supported as well.

* As the configuration of the LDAP server record leaves it open which 
attributes are used we should be able to accomodate any attribute 
structure of a LDAP server.

* For data mapping see above.

* For reusablity of configuration see above.

* SSO: The ldap_auth service defines a HOOK for Single-Sign-On methods. 
Basicly, it gives you the possibility to define one or more user 
methods with which you can try to find the username of an authenticated 
user and return the username together with a flag, that further 
authentification by the service should be bypassed.

* Authoristion management: Via the ldap_sync module it is easy to get 
usergroups from the LDAP directory. Via the flexible data mapping 
mechanismus it is easy to map the usergroup entries of a given user to 
the usergroup records in the TYPO3 group tables.

* Command line: We have already produced a CLI Module working on the 
LDAP server configurations doing the same as the ldap_sync backend 
module. It is not yet published.

* LDAP functionality. Just try to use the class tx_ldaplib in your own 
extensions. It's extremly easy to work with.



I hope I haven't scared anyone away with this rather lengthy email.
When you download the extensions please make sure that you get the 
manual.swx files as well. The system comes with a full technical 
documentation.
Please feel free to contact me if you need help during setting up and 
testing of the system.

Best regards

Daniel

--/

Daniel Thomas dpool

Hinderink und Thomas Partnerschaft IT-Berater und Projektmanager

Zenettistr. 20 | D-80337 München
t 08945227582 | m 01793918781 | fax 08945227583

http://www.dpool.net | http://www.typergy.com

/--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 9050 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-dev/attachments/20041117/1f4e14fe/attachment.bin>

More information about the TYPO3-dev mailing list