Kurt Zeilenga wrote:
On Jan 11, 2009, at 11:22 AM, Emmanuel Dreyfus wrote:
Kurt Zeilenga Kurt@OpenLDAP.org wrote:
Why? Generally, the web application is part of the service which encompasses the web server and directory service. They should already have an appropriate trust relationship.
When using plain password authentication, the web app can just hands the DN and password to slapd, it does not need any special privilege.
But a bug in the web app could not only give access the directory for all subsequent users of the web app, but also to other information/services protected by the user and password information available via that web application.
I thought a lot about the risks introduced by a web-based LDAP application. If a web application does not store user and password information because it keeps LDAP connections persistent in a web session then the risk is significantly lower than having a long-term service credential with a lot of power. (You might already have guessed web2ldap does it like this ;-)
That is, having the web application behaving as a kind of proxy, without any special privilege on the directory. Is that possible? If it is, where should I start?
Would require cooperation between the web server and the directory server. So nothing gained, IMO, except complexity.
This would be complexity in an unprivilegied piece of code, rather than giving trust to an application.
Not necessarily. The level of cooperation necessary, I believe, is so that the web app would have to be "trusted". And that's no better than the proxy authzid use case.
Kurt, one has to specify in detail "trusted for what". IMO proxy authorization is much more powerful than e.g. HTTP authentication with SPNEGO/Kerberos with the service being trusted to receive forwardable tickets (TGTs).
Both approaches have merits. In order to really compare them, one need an idea of the complexity.
How would one implement that kind of "proxy certificate authentication"?
I leave this as an exercise to someone who strong knowledge of TLS and its certificate-based authentication. I'm only saying it that it's likely possible, at least, in theory. I don't think it's practical.
I don't know of any existing mechanism one could use. Maybe a challenge-response SASL mech which uses Javascript signing at the client's side.
Ciao, Michael.