- Previous message: Joe Ammann: "Re: New authentication method"
- Maybe in reply to: Joe Ammann: "Re: New authentication method"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Alexey Melnikov (no email)
Date: Thu Dec 01 2005 - 06:33:45 EST
Joe Ammann wrote:
>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".
>
Yes. (This is not to say that no extra libraries would ever be allowed
saslauthd, but this will require more extensive changes to configure
script, etc.)
>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.
>
>
I think this is a bit simplistic, but let's defer this discussion until
you write some code.
>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?
>
>
Yes. Are you planning to use client side certificates?
|
|
|