Sponsoring a canon_user plugin for LDAP lookup

[Torsten Schlabach]

 > Heh heh. OK, you can paypal me at [email protected] whatever amount
 > you feel is fair. I'll send you an appropriate diff to ldapdb.c.

Ok, will do. ;-)

 > Cyrus provides a buffer of 1024 bytes for each username. If your DNs
 > are longer than that, we'll have to truncate them (and they'll be
 > useless).
 > I doubt this should be a problem for you...

You're right, we don't have that long DNs at all. Not even close to that.

 > Instead of doing that, we can
 > just overwrite the username that canonuser passes to the auxprop.

As long as it serves the purpose. Just recall, please ...

If you rewrite some at else.com to id000012 then you need to make sure that 
Cyrus IMAPd sees id000012 as it is going to use that as the name for the 
mailbox.

I need to say ... I am *not* sure about the sequence in which auxprop 
and canon_user are called. But isn't it that Cyrus IMAPd will take in a 
username, run it through canon_user (in case there is any), then run the 
rewritten username through auxprop to retrieve a password and compare 
the one that the user inputted to that.

So in pseudo-code this would be:

username = what the user entered as username
password = what the user entered as password

username = canon_user(username)

correct_password = auxprop(username)

if correct_password == password

   look for mailbox username

endif

If I was right with that assumption, than you could do anyting in an 
auxprop plugin to find the proper password (what you can indeed do today 
already using that authz rewrite rules) but you cannot change the value 
of username in the auxprop plugin. Isn't this why there are two 
different hooks, i.e. canon_user and auxprop?

On the other hand, as I said in my initial posting, I think the actual 
canon_user plugin would be not too complicated as it would just have to 
do a single lookup, i.e. use the given username in an LDAP url to find 
an object and return another attribute of that object as the 
canonicalized username. E.g. search for mailAlias=someone at else.com and 
return the uid attribute of the matched object.

Regards,
Torsten

Howard Chu schrieb:
> Torsten Schlabach wrote:
> 
>> Howard,
>>
>> > process the username, we don't change the name that SASL propagates.
>> > I suppose we could add a flag to the ldapdb configuration to say "use
>> > LDAP for the canonical name" and have it set the name in that case.
>>
>> Sounds good to me. So how about going for that "easy money"?
>>
>> We'll pay via PayPal!
> 
> 
> Heh heh. OK, you can paypal me at hyc at highlandsun.com whatever amount 
> you feel is fair. I'll send you an appropriate diff to ldapdb.c.
> 
> I'll note that ldapdb.c is an auxprop plugin, which is called just after 
> canonicalization has completed. Restructuring it to act as the canonuser 
> plugin would be a fair amount of work. Instead of doing that, we can 
> just overwrite the username that canonuser passes to the auxprop. Cyrus 
> provides a buffer of 1024 bytes for each username. If your DNs are 
> longer than that, we'll have to truncate them (and they'll be useless). 
> I doubt this should be a problem for you...
> 
>>
>>
>> Regards,
>> Torsten
>>
>> Howard Chu schrieb:
>>
>>> Torsten Schlabach wrote:
>>>
>>>> Howard,
>>>>
>>>> thank you very much for your suggestion.
>>>>
>>>> I think I had tried something with authz-regexp, but are you really 
>>>> sure that Cyrus IMAPd will actually see the rewritten username 
>>>> afterwards? I was able to take this to the point where the 
>>>> apropriate LDAP object was found and used for authentication, but 
>>>> Cyrus IMAPd would have still been looking for a mailbox with the 
>>>> original name rather than the rewritten one.
>>>
>>>
>>>
>>> Hm, right. This will establish the correct DN for authentication, but 
>>> nothing further; the DN that we get is kept internally. Since it is 
>>> possible that some other mechanism (like sasldb) may still want to 
>>> process the username, we don't change the name that SASL propagates.  
>>> I suppose we could add a flag to the ldapdb configuration to say "use 
>>> LDAP for the canonical name" and have it set the name in that case.
>>>
>>>>
>>>> Well ... will try, I don't remember having used
>>>>
>>>> > --enable-rewrite and manually enabled SLAP_AUTH_REWRITE.
>>>>
>>>> so maybe this is going to do the trick.
>>>>
>>>> Regards,
>>>> Torsten
>>
>>
> 
>