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 just ran into the same problem one hour ago. I had already installed XOOPS more than 20 times on Windows and Linux machines, without any problem. This time I am working on Debian Linux (sid). No messsages in the screen even if all log options were activated. No info in Apache and MySQL logs. The complete silence. Such a silence is only possible if your php4 and MySQL are badly linked together. I solved the problem on my Debian by removing my php4-mysql support and by reinstalling it:

apt-get update
apt-get remove --purge php4-mysql
apt-get install php4-mysql

And I was able to finish the XOOPS installtion.

I hope this will give you some tracks...

Benoit

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

rabideau se demande si il ne serait pas judicieux de faire du lobbying auprès des auteurs de Moodle afin qu'ils utilisent/incoporent XOOPS dans Moodle. Autrement dit leur proposer une fusion en bonne et due forme

I have some doubt on the real opportunity to do that. Different goals, different tools...

Anyway, thank you very much for bringing Moodle to my knowledge !

Best regards,

Benoit

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

===========================================
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

Dear XOOPS core developers,

Is it plan to include the described modifications to the next XOOPS version ? I am tired of doing manual updates to a lot of files each time I want to update my XOOPS version.

These are really safe modifications.

Thank you !

Best regards,

Benoit

P.-S.: I am ready to help you - I am a member of the XOOPS development team (myXoopsforge and WF-FAQ) but I don't know if this is the (preferred) way of doing things.

This is exactly what I would expect in the next XOOPS release

Benoit

Thank you very much for your feedback. I have corrected my post. I really don't know how this $ has disapeared !!! I have just check my production source code and it is there, of course...

Thanks again.

Benoit

Today there are a lot of great modules for Xoops2. Overall quality may vary from one to another, but they all solve reallife problems pretty well. The XOOPS core modules and classes are well designed and deserve recognition.

When a module developer starts coding, he has little documentation on how to develop his module and what are the best way to access the database, manage user permissions, store files, use notification system,... So he often starts from an existing module "similar" to the one he wants to develop. This is a good way to propagate best practices but also the worst ones...

Beside the propagation problem mentionned above, a lot of modules are doing identical things in different ways (file storage, image management, etc.). This is a huge waste of time for module developers and an error prone process. Furthermore it prevents the development of common behaviors between different modules or any kind of loose-coupled interoperability between modules.

In order to bring XOOPS to the next step, lets say the enterprise one, XOOPS needs a strong module development framework that will allow the construction of robust, extensible and interoperable modules. This implies at least 3 things:

- fully document the current core XOOPS framework
- identify common core module components
- develop, document and promote these new additions

I think the current organisation of the XOOPS team is perfect for supporting this. The Core or module team for development, the Documentation team for documenting the framework classes and the Quality Control team could ensure that new modules are "Xoops standard compliant".

IMHO, here are the most important things that the module developement framework should deal with.

1. Authentication
2. File management
3. Database abstraction
4. Simple Workflow engine

A new "team workspace" module could be developed in parallel to test and implement the framework under construction.

1. Database abstraction layer

Even if MySQL is and should stay the default database for Xoops, a database abstraction layer might be useful. The small performance cost of adding this abstraction layer ("never write a SQL statement anymore") should be nothing compared to potential architectural advantages. What about if MySQL guys introduce new way of writing queries, optimizing it or improving search mechanisms ? Let's the XOOPS user decide the database he wants to use. Just implement the MySQL classes. What about fulltext search in MySQL that is almost unique ? The interface should provide a search method. MySQL implementation will be easy to write and other database implementations will use proprietary mechanisms to achieve the same results. But this is not the XOOPS problem (see pear or ADO)

2. Authentication abstraction layer

The process of authenticating a user should be completely externalized and pluggable. We should be able to select the implementation that best suits our needs. A good way to follow is PAM or JAAS (an implementation of PAM in Java). A chain of loginModules implementation is the core of such a system. We should not have to hack core files anymore to adapt the authentication mechanism...

3. Filsesystem abstraction layer

The framework should provide an abstraction layer to store and retrieve files (either in the hosting filesystem or in the database). Every users and modules should receive a dedicated (private) space through this interface. The access rights should be based on the standard user/group XOOPS security classes. This would allow to build, for instance, common GUI components to store and retrieve files reusable throughout all modules or a Personal Web Folder to store and organise private files. All direct access to the filesystem should be prohibited. This could become the core of a real Document Content Management system: you could add metadata support, indexing, trigger workflows/indexing/process/etc., etc.

4. Simple workflow engine

Every objects have a lifecycle. Lifecycles may be very simple or very complex. They may need to be persisted or are just volatile. Let's imagine: when needed, you define a UML State diagram for your "stateful" object with your favorite tools. You export it to XMI and load it into your XOOPS Workflow engine. Don't forget to tell the engine if you need to persist the object states or not. That's all. You have completely externalize the workflow of your application. When you want to get/set the state of an object just send the approriate event to the Workflow engine... Am I dreaming ? This is already done by some frameworks... This kind of engine could greatly help in building more complex document approval flow (ex. FAQ, news, Articles, etc.) and open a lot of new doors for modules developers. Workflow engine is perhaps the most difficult part of the framework to design but it might be its greatest strongness.

5. OK, I won't talk to you about asynchronous messaging (MoM) ... today !

I am convinced that many things have already been done in the Free and Open Source world to help XOOPS building such a framework in a reasonnable timeframe.

The architecture of an Information System is more important than its source code availability. Even with the source code available some things can be impossible to realize due to a bad initial architecture. A good architecture should ease the participation and collaboration of modules developers. And the XOOPS authors have understood that from the early days. It is time to build a first class developer framework on top of the good core. This framework should also improve data reusibility. New modules and services will follow accordingly. If XOOPS succeed in it, it will really become the best Free CMS based on PHP and will have its place in the enterprise.

Now, let's start the discussion !

Benoit