From: <mi...@st...> - 2007-12-12 14:12:48
|
David Leonard wrote: > Geert Jansen wrote: >> Michael Ströder wrote: >>> Well, setting an env var is not really a good choice when running within >>> a multi-threaded web application... :-/ > > yet another reason to avoid threads? :) The multi-threaded approach gives me the possibility to use persistent LDAP connections. This is much faster. > Recapping the (interesting) problem: Michael wanted to pick out the > delegated creds from an SPNEGO auth'd request, convey them down to the > SASL GSSAPI auth underneath an LDAP bind. And have it all work inside a > threaded web server. Exactly. ;-) > If the request handler is a python script, then you would get a separate > python process for each request, and setenving KRB5CCNAME to a temporary > cred cache file for the delegated ticket is straightforward. This would be easy, but that's not how web2ldap works. > I know, > because I've done this. But let's say you want to be interesting and use > mod_python and have python-ldap code and sasl-gssapi running inside the > web server's thread. In this case, you might arrange for the spnego auth > to export the krb5 in-memory cred cache via an apache request note. I'd rather prefer to even extract the SPNEGO from the HTTP header within my web app since I don't need a Kerberos module for Apache then. And web2ldap runs also as a stand-alone server which is pretty handy in many situations. > However, when it comes time to prepare the SASL GSSAPI environment, you > get stuck because there seems to be no way to communicate to the krb5 > mechanism under sasl which cred cache to use for auth. Yupp. I already talked to Howard Chu about whether it's possible to change the OpenLDAP API (sasl_interactive_bind()) in this regard. > I think it would just be easier to avoid threads when using GSSAPI. :-( Ciao, Michael. |