Date: Wed, 25 Aug 2004 19:25:48 -0400
To: "Peter Leap" <peter_leap@filemaker.com>
From: Paul Davis <prd9@cornell.edu>
Subject: Desire to integrate FM Server w/ campus LDAP server
Cc: Robert Talda <rpt4@cornell.edu>, Tony Miller <tony_miller@filemaker.com>, Ronald Dinapoli <rd29@cornell.edu>
Bcc: paul.davis@gmail.com

Peter,

Here is the email I promised you.

I've met with the person implementing our campus LDAP directories and I've gotten a pretty good handle on what I think our options are for Authentication (I am who I claim to be, abbreviated as AuthN) and Authorization (In FM parlance, "I have the following privilege set", AuthZ) using our campus LDAP and Kerberos infrastructure. Because of the short time frame, I haven't run it by our campus experts on LDAP and Kerberos, but I've copied them so they can correct any miss-understandings I may have presented in this email.

For AuthN we use a Kerberos. I gather our implementation is based on the MIT code base.

For AuthZ we will be using an "authorization directory" hosted on a SunOne LDAP server (now called something like Sun Java Enterprise System and very similar to open LDAP and Netscape LDAP). (We currently have a "white pages" directory, but that will not contain things like FileMaker privilege set attributes or groups.)

For FileMaker 6 we've written a plugin for user authentication on the client side. Because we couldn't write a plugin on the server, it's a bit of a kluge. This plugin is used to set a global field that we use to control access to the records the user is allowed to see. While this was not an ideal Kerberos implementation, combining it with the normal FileMaker password system proved to be the turning point for getting permission to use FileMaker for our campus-wide grade submission system. That said, we would really like to do this plugin right.

With server plugins in FileMaker 7 we can do Kerberos *right*, but we would also like to take advantage of the wonderful privilege sets now available. We don't want to keep having to kluge authorization by stuffing a global and building our own authorization system to stuff another global with the user's rights. Instead, we want to leverage LDAP to stuff the privilege set value.

Simplest technically, but, probably politically untenable would be to have FileMaker use our LDAP directory for both authentication and authorization. Have FileMaker bind to the campus LDAP server over SSL, passing the username, password, database name, server name, and all FM Privilege groups for that dbase to query whether the user belongs to any of the privilege groups and if so, which one. We would create dynamic groups that would pass back the privilege set the user belongs to (if any), or, alternatively, whatever you do currently with Open Directory and Active directory. We will have tens, if not hundreds of different FileMaker servers so we have to deal with the namespace issue, but presumably you've already done that for AD and OD.

Technically this is probably not difficult and may, in fact, already be supported in your current product, though a perusal of the documentation on the web doesn't indicate either way on this.

Unfortunately for us, broad support of FileMaker by our central IT organization depends on FileMaker supporting single sign on using our custom infrastructure, and not storing passwords in our directory. I've been in lots of vendor meetings with our IT staff lately and one of the first things our IT staff ask about any new product is, "can it support our kerberos infrastructure". I'd like FileMaker to get this stamp of approval. It would almost certainly make FM a recommended solution instead of one IT wants to downplay.

To do this we can't be passing the password to LDAP, instead we want to authenticate the query and results using plugins we develop for FileMaker and  the LDAP. We've done this sort of thing many times before so much of the code will simply call existing libraries. That said, to do this, we need FileMaker to expose APIs for authentication and authorization. Because FileMaker already has LDAP connectivity in the server, it would be nice if we could leverage that in your API without having to include it separately in our plugin. (E.g.: pass the LDAP query to our plugin to filter before it is sent and the results to be filtered by the plugin when it is received.

There are lots of details, many of which I can address during a meeting and many more that I will have to defer to the domain experts here on campus. Importantly I can speak to the importance of the business need and the general outlines of the API we would require.

Thanks,
-Paul

______________________________________________
Paul Davis
Programmer/Analyst Sr.
Engineering Dean's Office, Cornell University
245 Carpenter Hall
Ithaca, NY 14853
(607) 255-6227 (office)   (607) 255-9606 (fax)
mailto:prd9@cornell.edu
http://www.engr.cornell.edu/IT
http://intranet.engr.cornell.edu