[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: web apps and client certificate authentication

Michael Ströder wrote:
Kurt Zeilenga wrote: 
The web application should just authenticate as itself and then use
proxy authorization to act on behalf of the client.
Of course, it has to be authorized to do so.

But it would be nicer to actually have the client authenticate to slapd
using its own client certificate.
Why? 

I also concur that it would be nice to have a end-to-end authentication
between web client and LDAP server without giving the web application
special rights.

But obviously the web application is a man-in-the-middle and current authentication mechanisms are designed to prevent MITM operation.

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.


BTW: This is a very broad assumption not valid in all deployments.
Nevertheless it's always good practice to avoid overly powerful system
components since in this case the web application could have security
problems.

Kerberos with forwardable tickets could be a solution. One could argue
that as a forwardable ticket is a full TGT you also have to trust the
web application a little bit more. But given the limited lifetime of
TGTs the risk is significantly lower than long-time service credentials
for the web application together with the right for doing proxy
authorization.

Still, that is your problem - you have to trust the web app to act appropriately on your behalf. If the web app has security problems, then sending any form of reusable credentials to it is a mistake.

As a hypothetical solution, one could use a combination of tickets and proxy authorization. I.e., the web app receives a client credential that contains both authentication to the web app and to the LDAP server. The web app then attaches (the relevant portion of) this credential to its proxyAuth'd requests to the LDAP server. The LDAP server then doesn't have to give blanket proxy privileges to the app; instead it allows the proxyAuth by virtue of the actual client credentials also being present.

In an X.509 framework, you might accomplish this by having clients generate their own sub-certificates (signed by their own client cert) with specific privilege attributes attached, and very short cert lifetimes (thus being analogous to Kerberos tickets in usage), and using these sub-certs to authenticate. Of course, nobody has developed a spec for any of this yet...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/