Re: web apps and client certificate authentication

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

Howard Chu wrote:
> Michael Ströder wrote:
>> Kurt Zeilenga wrote:
>>> 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

Howard, that's not a matter of "your" or "my" problem. In fact I don't
understand that sentence.

> - 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.

In an ideal world there are no security problems at all. The 2nd best
situation is that you know for sure in advance whether a component has
security problems or not. If it has it is a mistake to use it. Period.

But as we all know we're not living in an ideal world. So risk
management generally deals with the probability and the impact of (most
times unknown) risks. You can influence the probability by good software
design, code reviews and such. But that's most times outside the scope
of an administrator setting up a deployment. So the administrator can
only think about mitigating the impact of possible risks. This is not a
black-or-white situation.

And one could argue that the possible impact of security problems in
combination with proxy authz is higher than with a user impersonating
himself on the LDAP connection.

> 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.

Well, that's IMHO how forwardable tickets in Kerberos works except that
you don't need proxy authz in that game. (It's on my roadmap to play
with it.)

> 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...

Why so complicated? A challenge-response SASL mech could send the
challenge from the LDAP server to the web app which relays it to the web
browser where the user signs it with his/her private key.

A similar password-based approach would be to map HTTP-DIGEST authc to
SASL DIGEST-MD5. AFAIK that's not possible.

There are some SSO solutions for web apps. E.g. CAS issues a one-time
service ticket (CAS-ST) which is checked by the service against the
central CAS service. This could be sent along in a SASL bind request
with a custom SASL mech and then checked by the LDAP server (see
http://www.ja-sig.org/products/cas/overview/cas2_architecture/index.html).
Or the app could send the CAS-ST in a simple bind request and an overlay
would intercept this and check with the CAS server.

Ciao, Michael.