Subject: Adding an additional Authenticator

From: George Lindholm <[email-masked]>
Date: Thu, 10 Apr 2003 11:17:15 -0700

(I'm relaying this for a colleague of mine)

We need to add a new Authenticator to IMAP to handle our local
single signon mechanism. There doesn't seem to be any documentation
on how to do this (what files need to be created, modified, etc).
Could someone list the steps need to make everything work, it would make
our lives easier.
Thanks

      George

-- 
[email-masked]       ITServices, UBC
Programmer/Analyst

phone:    604.822.4375       fax:      604.822.5116

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Apr 2003 11:29:44 -0700 (PDT)

> Could someone list the steps need to make everything work, it would make

Are you talking about adding a new SASL authenticator, or something else?

If it's a new SASL authenticator, take a look at the LOGIN authenticator
(auth_log.c) and/or the CRAM-MD5 authenticator (auth_md5.c) to get an idea of
the framework that you have to do.

Once you've written an auth_xxx.c, then just add it to the EXTRAAUTHENTICATORS
when you build the IMAP toolkit and rebuild.

Here's a few notes that I've made.  Hopefully all should be clear now:

In the AUTHENTICATOR table, the only flags are AU_SECURE (meaning that
sniffing the session won't tell a bad guy how to authenticate) and AU_AUTHUSER
(has separate authentication vs. authorization users as described in the SASL
specification).  The other entries should be self-explanatory.

The client method calls *challenger to get a challenge from the server, and
*responder to send it.  Set *trial to 0 if you want to cancel authentication
(and this session), 65535 if you want to cancel retry with this mechanism but
allow a different mechanism, or just increment it if it is a password-type
mechanism.  The client method returns T if it is happy with the negotiation,
or NIL if it is unhappy.  Note that the actual authentication yes/no question
happens at a higher level; this "unhappy" refers to a protocol level error.

The server method calls *responder to send a challenge to the client and get a
client response.  If it is happy, it either calls server_login() (to validate
a UNIX-style password and log in) or auth_serverlogin() (if it has validated
the credentials itself and just wants to log in), then returns myusername().
Any failure should have it return NIL.