Re: centralized auth and nsswitch.conf

[Adrian Pavlykevych <pam@xxxxxxxxxxxxxxx>]

Richard Coleman wrote:

>Peter da Silva wrote:
>
>>> One simple way to achieve this is to support nsswitch.conf and have
>>> LDAP support as one of the available switches.
>>
>> For compatibility, I guess.
>>
>> The native name server would be accessed through messages and hide
>> as much of this complexity as possible from the application.
>
>That's the reason I'm hoping this problem will be given some thought.
>What is happening now, is that tons of applications are building in
>their own support for some type of centralized authentication or
>directory lookup.  Look at all the configure options for sendmail,
>postifix, sasl, mozilla, etc. to add LDAP support to look up information.
>
>I guess I've got this on the top of my mind since I've been doing some
>design work on FreeBSD to do centralized authentication and single
>sign-on.  The number of alternatives is very large, and all require alot
>of integration to make work.  Some of the choices you immediately hit are:
>
>0. Do you use the old school method (rsync passwords, whatever)?
>1. Do you use PAM, native LDAP, or native Kerberos funtionality?
>2. Pam can internally call LDAP (pam_ldap) or Kerberos (pam_kbr5).
>3. Kerberos can store its data in an LDAP server (patches to Heimdal).
>4. Your LDAP server can do native authentication, Kerberos, or SASL.
>5. SASL can do native database(sasldb2), use Kerberos, call an LDAP
>server, or use PAM.
>6. Etc.  The options go into a weird recursive loop.
>
>Richard Coleman
>
Richard Coleman wrote:

> Peter da Silva wrote:
>
>>> One simple way to achieve this is to support nsswitch.conf and have
>>> LDAP support as one of the available switches.
>>
>>
>> For compatibility, I guess.
>>
>> The native name server would be accessed through messages and hide
>> as much of this complexity as possible from the application.
>
>
> That's the reason I'm hoping this problem will be given some thought.
> What is happening now, is that tons of applications are building in
> their own support for some type of centralized authentication or
> directory lookup.  Look at all the configure options for sendmail,
> postifix, sasl, mozilla, etc. to add LDAP support to look up information.
>


In "packaging system" thread Matt wrote:

>     Well, I don't know enough about NSS switch to comment on it.  I do
>     know what I want to see for authentication and that is a port 
service...
>     a user level daemon, which takes and responds to requests from 
processes
>     for user, group, and other authentication info.  e.g. it would 
run the
>     password crypt check too, and would be able to ask for (opaque to 
it)
>     config files and environment variables from the requesting client in
>     order to resolve things like ssh keys, kerberos, and so forth. 
It would
>     deal with NIS or other over-the-network authentication systems as 
well.
>     All of that would be invisible to the requesting client.  I
>     really dislike having to compile authentication support into 
every program
>     in the system, even if it is in DLL form (like PAM.  I really 
hate PAM).
>
>     e.g., the conversation would go something like this:
>
>     program: help, I need to authenticate 'charlie'!  I have the 
following
>     pieces of opaque data:
>
>      - Something called a ssh2_public_key, whatever that is
>      - Something called ORIGINATING_IP, whatever that is
>
>     service: send me your ~/.rhosts, ~/.shosts, 
~/.ssh/authorized_keys file
>     please.
>
>     program: I only have ~/.shosts and ~/.ssh/... here ya go.
>
>     service: that's good enough, your authenticated for the following 
(opaque)
>     capabilities: (list of opaque capabilities)
>
>     program: Thanks!  I have no idea what these capabilties are but 
I'll hand
>     them out (one could be related to ssh that ssh understands.  If this
>     program is ssh then it will understand the ssh-related capabilities).
>
>     And so on and so forth.

What you are describing here is basically AAA client-server
communication protocol (like RADIUS). I was thinking about such
approach for some time, because usually we need not only plain data
lookups and password verification mechanisms (not even extendable like
PAM and NSSwitch), but also some rule driven decision system. E.g. I
want FTP access to be controlled by membership in LDAP groups FTPgroup
and Staff; mail delivery should be controlled via LDAP user object
attribute "maildir", forwarding via attribute "mailDeliveryProgram",
shell access is limited to members of ..., etc. You can easily add
more and more examples.

So what we need is something similar to FreeRADIUS
<http://www.freeradius.org>, but under BSD license and talking
DragonFlyBSD messages instead of RADIUS protocol. It should have
modules which handle data lookup (LDAP, SQL, DBM, ....), credential
verification (CRYPT, MD5,  X509, SSH, ...) and rules (to specify
something like: allow user with User-Name=jdoe with Cred=X509 access
Service=POP3 and use MaildirPath=/maildirs/jdoe as mailbox location).
This AAA server should also handle accounting, which can also be
extendable(!) - offloading syslog files from unnecessary data and
allowing applications store accounting data into files and or various
databases.

Regards,

Adrian Pavlykevych