On Apr 17, 12:30pm, Tillman Hodgson wrote:
} On Thu, Nov 25, 2004 at 11:21:50PM +0000, Dick Davies wrote:
} 
} > So you lose your SSO features anyway, and also you have no real
} > server identification (there are no tickets coming back from the 
} > server to the client). You'd have to rely on SSL CRLs to 'untrust'
} > a server, and we all know how useless they are.
} 
} As I said, PAM allows the odd app or two that might be preventing
} Kerberizing an environment completely to still work. It's a stop-gap
} measure until those legacy services can be properly migrated.

     I don't view PAM as a stop-gap at all.  The idea behind PAM is
that applications don't have to know anything about the myriad ways of
authenticating.  They just have to know PAM and PAM will take care of
the work of authenticating for them.  Today, we have basic user/pass
(with numerous ways of storing the password database), Hesiod,
Kerberos, smart cards, tokens (i.e. key fobs), biometrics, one time
passwords, and probably other methods.  How is every application
supposed to support all these methods?  How will applications written
today support methods created in the future.  Really, it has become
unreasonable to expect applications to support all authentication
methods by themselves without using some intermediary.  There is a
standard for an intermediary, and today, it is PAM.

}-- End of excerpt from Tillman Hodgson