Re: web apps and client certificate authentication

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

Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> 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.)
> 
> But a forwardable TGT is like a blank check - it can be used to acquire
> any other service tickets.

Yes. But in opposite to a clear-text password typed in a web form the
TGT has a limited lifetime like the short-time cert you proposed.

> Again, if you don't trust the app in the middle, this is not a good
> solution.

Yes, but the trust is not a black-or-white decision. If I surely know
that the web app is flawed it's a big mistake to use it anyway.

>>> 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.
> 
> Because a scheme like what you describe is inadequate. One of the
> factors in strong authentication is *mutual* authentication of all
> parties - proving that the client is who he claims to be and the server
> is who it claims to be. A pass-thru scheme like you describe will prove
> the client and LDAP server's identity, but will not establish anything
> about the web app's authenticity. When you have multiple parties in a
> conversation, all of them must be authenticated to the same level of
> trust, otherwise the whole exercise is futile.

"Web app's authenticity" is a very broad term. Even when authenticating
the web server where the app is running by validating the SSL server
cert you cannot verify the "web app's authenticity". So to some degree
you have to trust the web app itself (like Kurt already mentioned). But
again: Trust is not a black-or-white decision.

I see no reason why I shouldn't connect via HTTPS to the web app and
then have a pass-through authentication mechanism between the web
browser and the LDAP server to impersonate the user himself on the LDAP
connection. This is pretty similar to the user typing in his password
into a login form of the web app except that no clear-text longtime
credential has to be passed to the web app. (With assuming the web app
does not enforce any authorization at all and therefore does not have to
authenticate the user.)

Ciao, Michael.