Re: [ANNOUNCE] python-ad

[David L. <d...@ad...>]

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? :)

>
> I was thinking how one could solve the problem of per-thread credentials
> in python-ldap (or python-ad).. I think it can be done with the keyring
> credential cache code that is in recent MIT Kerberos distributions.
> Per-thread keyrings exist so if you set $KRB5CCNAME to
> "KEYRING:thread:default" then you should be able to use per-thread
> credentials.
>   

[A per-thread getenv() would be similarly interesting. I'm thinking like 
how errno was bodged as a macro.]

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.
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. 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. 
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.. This is because 
GSSAPI functions don't take context handles: it assumes global state for 
mechanisms. Even doing the "KEYRING" trick above seems dubious to me 
because the gss mechanisms might be squirreling away credential context 
in global storage. If I recall correctly, some krb5 implementations of 
gss are thread-clever, and might see different defaults per thread, so 
they might work.

I think it would just be easier to avoid threads when using GSSAPI. 
(Perhaps gss-v3 may be thread friendly?)






-- 
David Leonard                           d...@ad...
                                        Ph:+61 404 844 850