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

Re: web apps and client certificate authentication

Michael Ströder wrote:
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.


Generic "your" - probably should have said "the" instead.

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


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.

Yes, depending on how much freedom the proxying identity has. I should point out that OpenLDAP's ACLs allow you to define separate privileges for a user being proxied, vs a user that is authenticated directly. As such, you can easily limit the damage that an untrusted proxy can inflict on a system...

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. Again, if you don't trust the app in the middle, this is not a good solution.

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.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/