New authentication method

[Joe Ammann]

On Wednesday 30 November 2005 13:48, Alexey Melnikov wrote:
> Joe Ammann wrote:
> >That's what I got down to also. Good to hear that you agree :-)
> >
> >Looked around in the saslauthd code a bit deeper, adding a mechanism seems
> >rather straightforward. One question: Would there be any chance that a
> > clean patch would be accepted into the baseline of cyrus-sasl?
>
> Clean patch with no dependencies is likely to be accepted.

Great. By "no dependencies" I presume you mean "no additional libraries". Or 
are you referring to something else?

> >Currently I'm looking into adding 2 new mechanims:
> >
> >auth_externalscript: call an external script, pass it the info (user,
> > info, service, realm) via stdout, check the exit status of the script for
> > indication of success/failure, in case of failure take the first line of
> > stdout as the response string of the auth function
>
> Sounds like CGI :-).
>
> I need to think about this one.

Yes, that would be something like CGI. I thought that this might be a very 
simple way of extending saslauthd for sites with low volume of 
authentication. Of course, this mechanism would not scale very well. But it 
would give people a simple hook to plugin their mechanisms.

> >auth_httpform: pass the info to a HTTP POST form, expect either a HTTP
> > status 200 (meaning success) or 403 (meaning forbidden). In case of 403
> > take the HTTP response as the response string of the auth function
>
> What if you get a 5XX or another 4XX response? Make the code general,
> please.

Of course, it will also handle all other responses, but somewhat differently. 

200 would mean: positively accepted credentials
403 would mean: positively refused credentials (hopefully with some meaningful 
reason)

Anything else would mean: Something went technically wrong during 
authentication. This would be treated as if the HTTP server could not be 
contacted at all, or as if there was some problem within the saslauthd code. 
A meaningful reason would then be returned.

Later, I might make it configurable which HTTP codes will be interpreted as 
"credentials accepted" and which ones as "credentials refused".

BTW: It might be wise to offer the option to use HTTPS instead of HTTP as an 
option :-) That would of course mean that I would need the OpenSSL or GNUTLS 
libraries. Since OpenSSL is already used within several saslauthd mechanisms, 
I guess it would be acceptable if I used that one, too?

CU, Joe