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.