(RADIATOR) Feature Request: <AuthBy IMAPS>

[Mike McCauley]

Hi Charly,

On Saturday 13 November 2004 19:43, Karl Gaissmaier wrote:
> Hi Mike,
>
> Mike McCauley schrieb:
> > Hello Charly,
> >
> > Nice work.
> > I took the liberty of adding support for encrypted private key files with
> > SSLCAClientKeyPassword and testing with TTLS-PAP.
>
> fine, that's why I ask
>
> > The new version, plus a sample config file is attached.
> > Ill add it to the patches and the next release when you are ready?
>
> Not yet, after sleeping over it I'll refactore it
> to put also the _auth_imap() call into findUser()
> to circumvent the dirty hack with Password=Dummy
> and not giving the socket object in $self->{_imap_sock}
> out of control. I'll rewrite it to the following
> scheme

I dont know if thats right.
You have to implement check_plain_password, and it has to actually check the 
password, so I dont think you can refactor that way.

>
> findUser {
> 	$sock = _get_socket
>              or return problem with the database
>
>          create $user
>          $password = decode password from request
>          $success = _auth_imap($sock)
>          close socket
>
>          if ( $success )
>              add check-item Password=$password
>          else
>              add check-item Password=scramble($password)
>
>          return $user
> }

findUser is not supposed to behave like that. I think the way you have it now 
is better.

Cheers.

>
> that's it. When the authentication is successful
> we just stuff the request password literally as check-item
> so the SUPER->check_plain_password will match.
> When authentication fails we scramble(rot13, random, ...)
> the request password to be sure SUPER->check_plain_password
> will not match.
>
> Any good idea to scramble the password kiss-like in
> order to be sure that scramble($pwd) != $pwd and
> not come in conflict with the hidden logic in
> AuthGeneric::checkPassword, since as far as I
> see crypt($pwd) would be a problem.
>
> I would prefer an easy rot13 scheme.
>
> This is a more cleaner hack as the Password=Dummy to
> force a callback into this Class and giving the socket
> out of control.
>
> In the next few days (uups nights) I'll send you this
> corrected patch and also the AuthPOP3(2) with the
> same logic. How shall we name AuthPOP3(2), AuthPOP32
> isn't quite good, any suggestions?
>
> Best regards
> 	Charly

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.