===========================================
Pluggable Authentication Service for Xoops2
===========================================


1. Introduction
---------------

Just like XOOPS templates are a great way to personnalize XOOPS installations, Authentication Service mechanism aims to provide the same level of flexibility for the XOOPS authentication process. This hack only deal with authentication and NOT with authorisation (modules, function or page ACLs for instance)

Simply said, for each authentication mechanism you want to support, you have to write one and only one file with an implementation of the following methods (see sample implementations for more details):

function &loginUser($uname, $pwd)
function &loginUserMd5($uname, $pwd)
function logoutUser()
function loginPage()
function checkLogin()

Save this file under /include/authentication_services/, reference it in mainfile.php and apply the hack to system files (cfr. section "How to use the apply the hack")

I provide 3 different implementations:

1. The standard XOOPS implementation
2. LDAP implementation: user are authenticated against a standard LDAP directory and stored in the XOOPS DB. User's data are updated at each new user authentication
3. Central Authentication Service (CAS - http://www.yale.edu/tp/auth/) from the Yale University. One of the most clever and secure way to authenticate users of Web applications. It requires a running CAS server

The LDAP implementation could be very easily adapted to suit your specifics needs (LDAP structure/fields) and could even be used to authenticate users against Microsoft Active Directory.

IMHO this hack would deserve to be included in the next XOOPS (even minor) release It would allow to upgrade XOOPS without to have to re-apply authentication hacks everytime... Minus hack = smooth upgrades...

2. What has been done ?
-----------------------

4 new Files
/kernel/authenticationservice.php
/include/authenticationservices/xoops.php
/include/authenticationservices/ldap.php
/include/authenticationservices/cas.php
4 modified System files
/mainfile.php
/user.php
/kernel/member.php
/include/common.php

Click here to get the files

3. How to apply the hack ?
--------------------------

1. Copy the 4 new files (+ 1 new directory) to their final destination (on Unix/Linux, make sure that the new directory is accessible => chmod o+x authenticationservices/ )

2. Add the following line to /mainfile.php
define('XOOPS_AUTHENTICATION_SERVICE', 'xoops');
Note: later you simply have to replace 'xoops' by 'ldap', 'cas' or 'my_own_implementation' to dynamically switch the Authentication Service

3. Modify the three following "if" statement in /user.php

if ($op == 'main') {
if ( !$xoopsUser ) {
$authentication_service =& xoops_gethandler('authenticationservice');
$authentication_service->loginPage();
} elseif ( $xoopsUser ) {
header('Location: '.XOOPS_URL.'/userinfo.php?uid='.$xoopsUser->getVar('uid'));
}
exit();
}

if ($op == 'login') {
$authentication_service =& xoops_gethandler('authenticationservice');
$authentication_service->checkLogin();
exit();
}

if ($op == 'logout') {
$authentication_service =& xoops_gethandler('authenticationservice');
$authentication_service->logoutUser();
}

4. Modify /include/common.php

- Add the following line to auto-login code (around line 165)

// $authentication_service =& xoops_gethandler('authenticationservice');

- Modify this line in the auto-login code (around line 167)

// $user =& $authentication_service->loginUserMd5(addslashes($uname), addslashes($pass));

- Modify the elseif condition around line 215

} elseif (!empty($_POST['xoops_login'])) {
$authentication_service =& xoops_gethandler('authenticationservice');
$authentication_service->checkLogin();
exit();
}

5. (Optional) Delete the 2 following functions in /kernel/member.php (XoopsMemberHandler class)

function &loginUser($uname, $md5pwd) (standard XOOPS login function)
function &loginUserMd5($uname, $md5pwd) (used only by the auto-login feature)

6. (Optional) Delete the following system file
/include/checklogin.php

4. Current problems
-------------------
The only problem known today is related to the CAS Authentication Service when the XOOPS site is turned off: it prevents all users to login ! But I am confident: I should quickly find a solution. The problem could be partly due to our CAS server implementation. In fact I do already have a dirty work-around... Modify the elseif condition around line 215 in /include/common.php to match

} elseif (!empty($_REQUEST['xoops_login']) || !empty($_REQUEST['ticket'])) {

But this is really dirty since specific code to CAS service is added to generic code


5. Conclusion
-------------

This hack has been developed (I think/hope) in the "Xoops way of doing things" and with the KISS principle in mind (Keep It Simple Stupid). It does exactly what is supposed to do, not more, not less.

It is very flexible and you could imagine a lot of combination to authenticate your users: from another database, another corporate security&identy management system, https login page (alternative to the current option), etc.

And you can simply fall back to a working solution in less than 5 seconds in case of trouble by modifying your mainfile.php

Furthermore: it works ! I have been using it (the 3 implementations) for about one week on my production sites (about 100 users authenticate daily), without any trouble.

I hope you will find it useful.

Benoit
benoit.mercier@users.sourceforge.net

Quickys:
Does the hack prevent multiple logins?
URLs for any of your 3 production sites, so we can take a look?

Thanks.

What do you mean by multiple login ?

Unfortunately I cannot give you public URL's because we are using it on our own private Intranet. The only credibility I can give you (and the first official statement for the XOOPS community) is that we, the European Commission (http://europa.eu.int), have been using XOOPS to support our internal IT community (more than 1500 individuals) for about 2 months... More on this later, when we will reach 500 users (today about 115)

Benoit

This looks like a very good contribution. I might be able to make use of this on a few projects myself. Thanks for sharing.

If anyone else makes successful use of this hack, please post here and let us know how it goes.

I read it as it is functions, right?
Could it be changed to classes and have an "authentication" method chosen e.g. in site preferences (defaulting to normal of course)

I then imagine the authentication object to be instantiated like the Database instantiates MySQLDatabase based on a setting in the mainfile.php (but since we already have access to the database, it could be a XOOPS option saved there)

Then the code could be perhaps a little more clean or at least more granular.

2 cents? Or just 1 cent?

Hi Mithrandir,

This hack is full OO and based on classes and methods. In fact the XoopsAutenthicationServiceHandler class is just like the XoopsMemberHandler: a façade to manage AuthenticationService objects.

The 'xoops' AuthenticationService is just a "copy/paste" of the current kernel code. I did not touch a iota of it

You are right, we might instanciate the object only once at the very beginning just like database object, instead of instanciatate it every time we need it. But why keep in memory on object that is only used at login/logout time?

But I am certainly not an expert of the XOOPS kernel. I would appreciate that Skalpa, for instance, could give us his opinion on that.

My 0,02€

Benoit

I didn't as much mean that it should be instantiated once instead of on a per-use basis.

What I meant was that it was decided by looking at a XOOPS config setting, what authentication type (i.e. class) to instantiate.

Great. This just may be the thing we need right now.
Thing is, our firm already has several installations of XOOPS so we'd like to integrate it with our existing Novell eDirectory. On top of this, we're gradually implementing Single Sign-On for all, if not most of our apps.

Just to verify, since we have several XOOPS installations, does this mean we have to do the steps you mentioned for each XOOPS site that we have right now?

Also, would this work with XOOPS ver 2? We're using ver 2.0.3 right now.

Thanks mercibe.

- Allan

Depending on the way you would like to achieve SSO, this hack could help you to isolate your specific code without having to hack the XOOPS kernel. But you will have to apply the steps for each XOOPS sites (1 time + x file copy operations) unless you wait for the XOOPS 2.2 where this hack will be part of the new XOOPS kernel.

I am using this code on a 2.0.6 version.

I think you should be able to simply use the current provided LDAP "module" and modify the parameters at the very beginning of it to use with your eDirectory, without touching a iota of the code (it's the goal!). It should not be the case with Microsoft Active Directory, but I still have to try. If someone has already tried, I would be nice to share your experience with us here...

I would be interested to know the technical solution you are going to use for SSO. We are using CAS to integrate Coldfusion, Java Swing client, JSP, PHP and perhaps soon old Powerbuilder applications. You could develop a authentication module for your SSO authentication just like I have done for CAS.

Hope this will help !

Benoit

I was unable to get this to work with my Windows 2000 Active Directory. Can you provide any help? I know that it is binding to the server, but it is not authenticating users.

Thanks