On Mon, 10 Mar 2003, Philip Hazel wrote:
> This sounds like item 59 on the Wish List:
>
> ------------------------------------------------------------------------------
> (59) 26-Jun-02 M A "custom" authenticator
>
> ... that is simply a front end to external code. For example, there may be
> an external API that hides the user password and does CRAM-MD5 when passed the
> details of the challenge and response.
> ------------------------------------------------------------------------------
>
> > 3) if I implement this variable cleanly, is there a chance of it being
> > adopted into the main source tree so I don't have to maintain a branch?
>
> I think this will need a whole new authenticator in addition to the
> variable, but I have not thought about this at all.
after I implemented PLAIN and LOGIN as radius queries, I found out that
our radius server lies about the passwords for some users (This is done on
purpose and makes sense in the context of NASes). I could probably fix
it, but given this obstacle and the exim work, I'm dropping it at least
until #59 is implemented.
That said, I still think it could be done with plaintext:
radius_cram:
driver: plaintext
public_name = CRAM-MD5
server_prompts = $auth_cram_challenge
server_condition = ${if radius{$auth_cram_challenge@cram:$1}{yes}{no}
but it's moot now, I guess...
Thanks
--John
