Pluggable Authentication Service
This is a more technical look at one of Plone's great features for the Enterprise, its authentication system. If you just want to know the high level benefits then read the previous post, if you want to know the nuts and bolts of a real world scenario then continue reading...
To recap, Pluggable Authentication Service (PAS) allows you to break up the authentication process into small steps and have individual plugins deal with each step.
But how does this work in reality? We have a client we are developing an intranet for whom need NTLM authentication. NTLM is quite a complex challenge/response mechanism, but allows users on Windows PCs to be transparently logged in to a web server using the credentials they supplied when they logged in to their workstation. We had to write a plugin for this as there wasn't one for Plone around (and we'd already done some NTLM work many years ago, so knew how it worked).
The NTLM plugin was responsible for telling the web browser to use NTLM (ChallengePlugin); extracting the credentials from the user (ExtractionPlugin); and actually authenticating the user (AuthenticationPlugin). So that gets the user authenticated, but all we know is the users username then (which in this company is just a random number). We need to get some more information about them such as their real name and their email address. Well there is an existing add-on PAS plugin that can get that for me, LDAPMultiPlugin. I can configure the LDAP plugin to look up information from Active Directory: the user's name and email address (PropertiesPlugin); Search/List all users in the company (UserEnumerationPlugin). I can also use the same plugin to lookup what groups a user is a member of (GroupsPlugin).
So, we are authenticating a user via one source and then looking up further information about the user and their groups from another source. However we want to assign the users roles in the intranet. This information is just specific to the intranet, and so whilst could be stored in LDAP it probably wouldn't make much sense, and we should probably store it locally. That's not a problem, as Plone comes with the ZODBRoleManager plugin which stores the roles locally.
We can even take this a step further: as setup above, every request to the web server causes a lookup to the domain controller server to do the NTLM authentication, which is a bit of a waste. Plone comes with a 'session' plugin which uses a cryptographically signed cookie to authenticate users which can be enabled for extracting credentials (ExtractionPlugin) and authenticating (AuthenticationPlugin). We now have two separate authentication plugins, NTLM and session. Plone will try both of them to authenticate a user and stop once it is successful, so if we put the session plugin at the top of the list that will be tried first, then if that doesn't work (ie this is the user's first visit to the site this day) it will try the NTLM one.