Re: web apps and client certificate authentication

[Michael Ströder <michael@stroeder.com>]

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.