Great news and congratulations !
I planned to have a look at this PAM module this weekend...
1. Users, even when authenticated outside of the XOOPS scope, have to be inserted in the XOOPS DB. This is mandatory since a lot of modules/tables reference them by their unique xoops_user table identifier (a good thing). So you are right, almost all authentication modules first authenticate the user via LDAP or AD for instance, insert/update user data in XOOPS and continue the normal XOOPS authentication process. So users are authenticated twice and, you are right, the password (not the password, a hash key only) of the external system is kept in the XOOPS DB. But it is updated at each new user login. This is the only way to allow a mixed authentication: external XOOPS users and XOOPS only users. But this way of doing is NOT mandatory. For the CAS module (strong security), XOOPS do not even receive the password of the user. The page that perform the authentication is a non XOOPS page. So, the CAS realm users are the only ones able to connect to Xoops. But I still have to add them to the XOOPS DB. So I generate a fake password based on the username in the password field. I have even implemented and deployed a mixed CAS and XOOPS authentication module (not published yet on Internet
) that, based on the username (and the fake password algorithm) redirects the user either to the CAS login page or to the XOOPS standard page. The authentication process is splitted in 2 phases: first the user has to enter his login and then his password, either in the CAS page or XOOPS page. This is a complex and powerful module
Conclusion: if you need "mixed authentication" (Xoops+PAM) and do not want to store the "PAM" password in the XOOPS DB, generate a fake one based on the username (using your own function/algoithm). So that the password is kept secret (more or less since XOOPS at one moment in time owns it and YOU could do anything with it...). This is one of the strenghs of mechanisms like CAS. If you do not need mixed authentication (PAM only), you can even modify the code to not authenticate users twice. I suggest you do that in your own separated authentication modules, so that when XOOPS will integrate this hack in a future version you won't have to hack anymore
You can always keep the original modules and work/hack on copies with other names.
2. Unless you use a completely externalized authentication process (like CAS) with full SSL (HTTPS) encryption during the login process, you won't have the minimum needed to a more or less secure system. A "very secue system" does not mean a lot of things to me. What about the process of password lost, modification, etc. ? A delay between erroneous failed authentications can only prevent you of brute force password attacks. And
this should be implemented by the underlying PAM authentication system, not Xoops.
For syslog use, adapt your code as you like using PHP's syslog functions (http://www.developer.com/lang/php/article.php/3327111)
For redirection to the Homepage, you could use a Session variable to hold the number of failed attempts. At the third one, reset to 0 and redirect to home page.
It would be interesting to have that 2 last possibilities as options for all authentication modules, wouldn't be ?
Best regards,
Benoit
