VFS Implementation and user authentication

[Nicolas Williams]

[NOTE: I cannot find any Samba list web archives that: a) are pleasant
       to use, b) display Message-Id: headers, so I'm breaking threading
       here. No archives?, Me no follow. (Well, me barely follow)]

I'm working on a doc based on Andrew Morgan's PAM RFC update draft,
using his binary prompts ideas to specify an interface between PAM and
remote pass-through authentication systems (NTLM, Kerberos, whatever).

I'll use SSO (single sign-on) to refer to those auth system. SSO really
requires two things:

 a) initial basic authentication (username/password, biometrics,
    smartcards) and

 b) remote, cryptographically secure pass-through authentication

PAM is great for (a) and does not help with (b). But with Andrew
Morgan's binary prompts backwards compatible extension to PAM it is
possible, IMNSHO, to specify the way applications should interact, via
PAM, with PAM modules which implement (b).

There's been two long public threads on this subject on the Linux-PAM
and, partly, krb-dev lists. Andrew has convinced me that this can be
done using binary prompts instead of the hairier things I originally
wanted to do.

The idea is, briefly:

 - the server app calls pam_authenticate()

 - the PAM SSO modules use binary prompts (through the server app's PAM
   conversation callback function) to drive the exchange of auth tokens
   with the client

 - this will work with AND withOUT protocol changes

 - there will be an option for the app to do the auth loop itself then
   call pam_authenticate() and have the conversation function return to
   the querying module the parameters of the authentication that went on

 - PAM will give the application access to the auth mech specific data
   the app may need to do session encryption and the like

 - PAM SSO modules will have a chance to map remote user principal names
   to local Unix usernames if the application has not set the PAM_USER
   item

 - PAM SSO modules will have a chance to authorize access by the remote
   user principal to the PAM_USER account (think ~/.k5login)

The proposal will include a behaviour pattern that these modules should
stick to, example pam.conf setups, and so on, including details of how
SASL and GSS-API modules should interact with the PAM application and
other modules.

This will make it possible to have ktelnet, krlogin, gssftpd, Samba, and
many other such programs use PAM.

Nico
--