Anthony Baxter wrote: <snip>

It should work against any particular LDAP server - if it doesn't, then we have a standards incompatibility problem.

One thing I wasn't entirely sure on, last time I looked at this - is the username/password type schema properly standardised?

Jeffrey added a clever option to the LDAPUserFolder which lets you map arbitrary LDAP attributes into the username and password fields. In our case, (iirc) the inetOrgPerson has a userid and password field in the standard object schema.

...

I think this is HARD. If your use of "authorizer signature" means a digital signature of the requisition, you're in for some pain. Zope has no organic crypto (save the nifty hashed password stuff). Getting and talking to an X509 cert will be some work.

But a client-side cert acl_users would be way, way cool.

I agree!!!

...

Yes and no. Certainly redhat's secure server and stronghold can use Verisign certs. However, I'd bet a nickel that all they would do by default is pass a securely bound Distinguished Name (DN) to the Zope proces. You're not likely (although I could easily be wrong) to get any of the crypto stuff (e.g., public key).

Yeah, you may be able to get stronghold, or something, to do the client-side certificate auth. Hey, didn't Chris Petrilli work with this stuff?

Yep. We've now got the expertise, we've just not had the opportunity to get into it. The customer driving our LDAP work will, in the next 3-4 months, also be driving an x509 requirement. When we do get to it I _strongly_ suspect that we'll defer as much as possible to the web server (in their case Netscape ES). --Rob