LDAP required?

[debianfoo]

is LDAP required?

why wouldn't I want to just cache permissions in memory from a database call?

update- just found this from a search: Authentication via ODBC possible?

I assume the authentication layer is 'pluggable' in the next beta?

maybe I just have a bad taste left over from past exposure to LDAP repositories, they seemed to complicate our application model when used about 2-3 years ago - of course we were building one of those 'enterprise' java apps, so everything was complicated...several 'enterprise architects' later (avg half life of about 3 months), well you know the story

since I'm editing this post now that I found additional info from a search of the forums - and I'm done ranting- my primary questions are:
Why would I want to use LDAP? (assuming no legacy ldap user store to worry about)...most seem to already have a database somewhere in their environment but few (?) have ldap - am I missing some justification?

thanks.

[KevinH]

LDAP is designed for read heavy structured data. This is what we put in there. Most enterprises use LDAP to manage user data, so while you may not most do. Of course the source code is available so if you'd like to make changes for your environment then the code it there for that.

The next beta won't have the pluggable auth framework but again it's close enough now that with a little coding you can make it so.

[debianfoo]

Thanks Kevin.

Are there any benchmarks that actually quantify the performance benefit of LDAP? Internal from your group, or external on the web. I googled, but did not find anything compelling.

I understand the need for trying to conform to what most enterprises already have deployed, that was our reason for using LDAP also (when I worked in software dev). But now, I am just part of a small academic group looking at email solutions - and LDAP seems like one more thing to worry about. We already have many databases that we admin.

In my past life, I just recalled that it was one more system for admins to learn (if it was not already installed at an enterprise) - and indexing the user table in a RDBMS with an in memory cache at the app layer seemed to allow a simpler install and was more performant (for us). We were using iPlanet at the time - and had to monkey with getting the LDAP trees into memory anyway, in the end (because of performance problems).

Thanks again for clarifying this matter. I'm far from an expert in this area, and given all of the great work that your team has done, I assumed there was likely a good reason that you were using LDAP.

[schemers]

LDAP provides a number of benefits:

1. centralized configuration, good when lots of servers need access to the same data
2. well integrated with MTAs (for mail routing)
3. can be used for authentication
4. can be used for a global address list/corp directory, and is supported by MUAs (Thunderbird, Outlook, etc)
5. you can replciate the data, for high availability

We've done our best to try and hide some of the LDAP management issues, but it is still there.

Internally the system was designed around some Java interfaces/abstract classes (com.zimbra.cs.account.*, Provisioning.java in particular), with our implementation via LDAP (com.zimbra.cs.account.ldap.*).

It is possible that you coulld actually back all the accounts, config, via a database like MySQL by writing a MySQL version of those interfaces. This might make sense for a small/single-node install.

The remaining issue would be Postfix mail routing, but you could write some Perl/Java/Ruby that pulled the data out of the server and put it into dbm maps that Postfix looked at.

Ideally someone in the community would do this work and contribute it back

roland

[bmiddleton]

I had the same feelings about using ldap until I ran across a little known FREE app called Penrose, it's a virtual LDAP server that maps to fields in a backend database. It's Open Source and based on the ApacheDB, 100% java so it works on multiple platforms, and very easy on the cpu. They also provide a GUI based application for mapping the feilds in your database to the LDAP feilds. It also includes a configurable cache so it doesn't have to hit the db as much.

Penrose - Virtual Directory Server
http://penrose.safehaus.org/

For those of you with content management systems like Mambo or DotNetNuke....
I'm using Penrose to allow users who signup to our portal and after we approve their access to have an account in Zimbra. So their account is really in the portal user database. They can change their password and profile in the portal as much as they want and Zimbra stays updated. If we remove there account for whatever reason they can't access Zimbra anymore. We also provide GAL via LDAP based on the information in the database.

The only issue I'm still working on is single logon, so when they log into the portal the are automatically logged into Zimbra. Maybe one of the Zimbra guys can help me with that one....?

hope this helps....

[KevinH]

Originally Posted by bmiddleton

The only issue I'm still working on is single logon, so when they log into the portal the are automatically logged into Zimbra. Maybe one of the Zimbra guys can help me with that one....?

Single sign on is easy. You just need to use our SOAP API (see ZimbraServer/docs/soap.txt in the source for full details) to get an auth token from the server using the username/password. Then set the auth token a cookie and finally redirect them to Zimbra.

A sample SOAP request is attached.

The Java code to set the cookie and redirect would be:

Cookie authCookie = new Cookie("ZM_AUTH_TOKEN", authToken);
authCookie.setPath("/");
res.addCookie(authCookie);
res.sendRedirect("http://yourzimbrahost.example.com/");

[debianfoo]

thanks for the great help, I'm amazed at how responsive the Zimbra team is

penrose should do the trick

we actually also have a small wiki/knowledgebase app for sharing docs, semi structured data, etc. - it provides a pluggable auth layer (it can use an LDAP store, etc.), and we already have a RBAC model in the db, but Penrose looks to be the simplest route to exposing this model to Zimbra - no migrations, and everything is still in the db