[Date Prev][Date Next]
Re: web apps and client certificate authentication
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
>> 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