User authorisation class

Hi there, about two weeks ago we had this discussion about a new authorisation / authentification class where I announced that I have one in the making. Unfortunately it took me a little longer than expected due to some important projects coming up at work. However, I am back on the topic now and want to ask for your advice. One of the package´s features is that you can store user ACLs in many different storage containers. When you try to login, the class can be configured to try to find a user in one or more of those containers in a defined order. I added this to solve the following scenario: A company starts an extranet for sales partners. The company´s partners can register themselves through an online form. Their user information and access rights are stored in a local database on the webserver. The company itself has several hundreds of employees who need to have access to the extranet, too. As all employees already have user accounts the company´s LDAP server, it would be stupid if they all had to register through the online form and keep duplicate records (one on the webserver´s database, one on the LDAP server). Therefore, the user class is configured to look for user information in the local database first, and when the user wasn´t found, to search in the company´s LDAP server. I have thought about a number of possible solutions for this problem, but I can´t decide which solution is the best. Maybe you guys can help me. These are my possibilites: 1. The user class has a list of servers with their respective login information stored in an XML file. When a user tries to login, the class makes a new connection to each of the servers/containers until a match is found. 2. The user class does not do any connections by itself, but you can pass connection objects to it (ie. a PEAR::DB object that already contains an open connection) that are then used in the order they are passed. 3. The user class _always_ uses SOAP or XML/RPC to connect to a central authentication server. That server then manages the connection to the true storage containers. Solution one is probably the easiest to implement, but it also implies that you might open at least one connection to a container that you already use in your application - normally that being a local database. This connection would not be reused. Solution two reuses connections that you might already have made, but you´d have to make other connections yourself as well, regardless of them being neccessary or not (you don´t know in advance in which container the information for this specific user resides, so when you make three connections and the info was in the first container already, you have made two more connections that are obsolete). Solution three is probably the most flexible and elegant one, but due to the nature of the XML-based protocols, it adds connection overhead. What do you guys think? In which direction should I go? Regards, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1