We administer the Greek School Network Directory Service which currently contains more than 170,000 entries including school accounts for email and dialup access, teacher accounts and several student accounts (though this service is just starting). Services include email accounts, dialup access, web pages, VoIP and others. User administration is done through a feature-full web administration interface created by CTI at Patras. This administration interface includes powerful features like:
- Maintaining referential integrity for configurable attributes
- Maintaining attribute uniqueness
- Creating attributes based on the value of other attributes (to be exact any php function or expression may be used when computing attribute values which is even more powerful).
- Performing post operation tasks like creating user directories, sending welcome emails and so on.
Greek School Network is moving towards the e-school framework which apart from the currently available services includes:
- A web portal (sPortal) for student parents which allows them to view student data like missed classes and others
- A school administration platform which will move all school operations (student enrollment, classroom management, grading) to the electronic world.
These new services create new sources of information for the existing Directory Service. Parents will obtain accounts in the web portal while the school administration platform will create student accounts for all the Greek students. Allowing these services to administer these entries through plain LDAP poses some serious drawbacks:
- Each service only has knowledge of it’s own little world (and attributes). The sPortal for instance just needs to create simple parent username/password for access to the Portal. It is not concerned with the fact that the created account might also be entitled to email or VoIP access.
- There is no way to perform post operation tasks like creating user directories.
- Each service is given too much power over the Directory Service. There’s almost no control (apart from ACIs) of what is added to the directory and no constraints can be set on the incoming attribute values (ok you have that ability in latest OpenLDAP releases but you get my point).
The way we decided to overcome the above difficulties was by creating a web service interface around the already excisting user interface. The web service uses WSDL and SOAP over HTTP(S) to create a function interface to all abstract operations needed by the external services. Each time a parent has to be created in sPortal for instance the portal will call the CreateParent() functions with appropriate arguments. This function will perform all the necessary checks on the arguments and call the internal object creation function of the user administration interface. That way:
- We use the same function backend for both the user administration interface and the web services.
- Complete and configurable logging of all operations is available with much more detail than that provided in LDAP server logs.
- Referential integrity and attribute uniqueness is already available in the administration interface backend.
- Computed attributes values are available using any valid php function or expression for computing values. Something like Class of Service but with much more power and control.
- Pre and Post operation tasks can be performed through the backend (which can call outside scripts or other web services).
- All operations pass through a single point where we have complete control over what happens and by whom. We can set constraints on attribute values and do extra checks on these values (for instance we can make sure that an incoming certificate actually belongs to the corresponding user entry).
- Outside services don’t need to have deep knowledge of our entry scheme. They just need to call already defined functions (with the minimum set of arguments) and the web services/backend handles the rest. We are free to change the entry scheme whenever we want, adding or removing computed and static attributes to the ones sent by the web service.
- We can impose our own entry expiration policy. The EntryDelete() web service function might end up just setting an active=false attribute inside the entry allowing us to decide when to actually delete the entry and/or perform any other tasks necessary.
Unfortunately, we cannot release the administration interface to the general public. We hope to be able to do that in the near future though since we have to create a web service interface like the one described above for the e-University project. In my opinion things are going to move to the realm of web services as far as writes are concerned. DSML is already available in most LDAP server offerings; creating a web service function interface around the actual LDAP operations is the next step forward in my vision. That is the vision of the XML Enabled Directory Internet draft. Although i believe that just translating LDAP operations to XML is not enough. In our case doing that would:
- Increase web service development time proportionally
- Negate some of the basic advantages of the current schema. Clients call abstract functions (ParentCreate(),ParentUpdate()) and don’t need to trouble themselves with the underlying database (LDAP), the semantics of LDAP operations or even the complete entry schema (they only need to provide basic user information, the rest, like creating objectclasses or produced attributes is handled by the underlying function interface).
Providing an inteligent backend/library in order for directory administrators to easily produce an abstract operation web services interface to their existing directory infrastructure for outside services is what i would like to have available in the end.
7 comments
Comments feed for this article
April 19, 2007 at 1:33 pm
Movind LDAP writes to Web Services - The interface « A world of LDAP and RADIUS
[…] April 19th, 2007 in LDAP, Web Services, PHP On a recent post i pointed out the advantages of moving ldap writes to web services. I also stated that we […]
April 30, 2007 at 12:05 pm
Dionysios Synodinos
If I understood you correctly, you use web services as a mechanism to provide a standard interface between the two systems that also serves as an abstraction over the multiple LDAP operations that might be required for a given system operation. I’m not familiar with the specifics of the LDAP protocol or the exact features that contemporary Directory servers support, but isn’t there a way to extent or “overload” the standard LDAP operations? For example can’t you define new operations that serve as an aggregation of numerous basic/standard ones? I would find it strange if there wasn’t such an extention mechanism and even stranger if the vendors haven’t come up with something similar to close the gap.
Is the introduction of yet another layer like web services for something that looks so obvious/common necessary? Is the protocol and the implementations so poor in features?
May 1, 2007 at 8:13 pm
kkalev
Answer to Dionysios:
The LDAP protocol allows for creating new extended operations or controls on already existing operations. This however involves quite a lot of work in defining the extensions and writing code (on both the server and client end) to implement it. You need deep knowledge of the inner workings of your ldap server to implement them and any bugs/problem in your code will take the whole server down. So it’s a solution that:
* Does not scale
* Is error prone
* Is platform specific (a plugin for Sun ONE will not work for OpenLDAP)
* Involves too much work implementing it
* Requires LDAP operations instead of using web services (which is a big plus if you are dealing with outside web based clients)
LUMS could theoretically be written as an LDAP server plugin but that would require writing it in C instead of PHP (which is a lot more work) and creating one version for each LDAP server available on the market (or maybe just creating a back-perl backend for OpenLDAP in order to save time). In general, too much work, too much risk with minimum benefit.
August 2, 2007 at 9:48 pm
Web Services interoperability fable with Java and PHP « thoughts.iterator()
[…] access, teacher accounts and several student accounts. For various reasons that you can find at my colleague’s blog there was a need to perform LDAP operations over WSs – in fact we had to “Move LDAP writes to […]
December 16, 2007 at 2:00 am
Idetrorce
very interesting, but I don’t agree with you
Idetrorce
April 25, 2009 at 10:54 am
Using Syncrepl ideas to build a web services based database to LDAP synchronization mechanism « A world of LDAP and RADIUS
[…] 25, 2009 in LDAP, PHP, Web Services | Tags: LDAP, syncrepl, Web Services In previous posts i pointed out the benefits of using web services (instead of direct LDAP access) to perform LDAP […]
January 30, 2013 at 6:16 pm
Shane
Attractive section of content. I just stumbled upon your site and in accession capital to assert that I get in fact
enjoyed account your blog posts. Any way I’ll be subscribing to your feeds and even I achievement you access consistently quickly.