Authentication plugin returns success but still returns to the login screen

[Stephen Palmstrom]

I am reposting and rewording this here, as I understand this is where you want such posts to go.

I wrote an authentication plugin for Joomla following, I believe, the instructions for such plugins in the Joomla documentation, to allow someone to use their Microsoft Office 365 credentials single sign on to Joomla.  It worked for several months, but since recent updates to Joomla it has stopped working and instead returns the user to the Joomla login screen.  It is effectively authenticating against Azure Active Directory.

The logic is as follows:

1. Attempt to log in to Joomla with a guest login and random password.
2. Joomla authentication fails, so the authentication is passed on to the custom authentication routine.
3. The authentication routine calls another PHP script that validates against the Azure Active Directory.
4. This PHP script calls the Joomla index.php again.
5. Joomla authentication fails, but the custom script now picks up the MS credentials, maps to the Joomla user name and returns success.

 Despite return success, Joomla fails to acknowledge that the user is logged in, and returns to the login screen.  If you log in as an administrator, you can see the user appears to be logged in to Joomla.

I have spent a few days attempting to debug this, but without success and am at a loss to know where to go from here.  Of course, if someone can suggest an alternative authentication plugin, that would be great.

Per Yngve Berg requested I upload the files, so I have uploaded the key ones, namely the authentication script and the one called to authenticate against Office 365.

Can anyone suggest a way forward?

[Stephen Palmstrom]

In the absence of any response, I did some more investigation.  As I suspected, it was something to do with the session variable: 

1. In  <joomla_root>/plugins/user/joomla/joomla.php a new session is created by $session->fork() on around line 222 in the onUserLogin function. The old session is purged from the database.
2. If you logged in using Joomla authentication, the new session is sent when the application runs after login.
3. If you logged in using the SSO application, the old session (or at least its ID) is sent after login, so naturally Joomla doesn't realise you are logged in and returns to the login page.

Commenting out the $session->fork() and database clearing statements further down 'solves' the problem, but it is clearly not a solution as the fork statement must be there for a reason, possibly to do with two factor authentication etc.  What is the process of sending the new session when the application runs again after login is complete?  I haven't discovered where this is supposed to take place.

Clearly this 'workaround' can't be put into production - there needs to be a better solution, so can someone advise?

Many thanks.

 

[Michael Babker]

$session->fork() migrates all of the existing session data to the new session so there is no data loss.  So now my question is what are you doing that is reliant on a persistent session ID, since it seems your issue lies in the fact that the authenticated session has a different ID from the guest session?

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send email to joomla-dev-general@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

[Stephen Palmstrom]

I am not relying on any of the session parameters, what seems to be happening is that the session variable has forgotten the forked session.  Incidentally, I've tried various browsers.  The issue only occurs in Edge and IE.  Chrome, Firefox and Opera do not show the issue which is most strange.  I discovered that if I did not call the authentication page, but pretended I had its results, the problem did not occur.

On Wednesday, 9 November 2016 10:06:18 UTC, Stephen Palmstrom wrote:

[Michael Babker]

Hmm, without seeing your setup then I wouldn't know how else to continue. Some had indicated their systems relied on the session ID staying the same after the login action, that and the timestamp should really be the only external variables in the session data changing (well, the serialized JUser representation will too, but all the other data should persist unchanged). If the app is trying to share the session in full with an external app (which you can do if you know what you're doing), it could be problematic too I guess.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send email to joomla-de...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--

- Michael Please pardon any errors, this message was sent from my iPhone.

[Stephen Palmstrom]

Thanks for getting back.  The application isn't trying to share the session with another script - the script posts data that enables the custom login to authenticate using the Office 365 data.  What is happening is that after authentication and index.php runs again, in Edge the old session ID is that of the session variable returned by

$session = JFactory::getSession();
$session_id = $session->getId();

(entered in index.php for debugging purposes), whilst with Chrome it is the new session ID.  Obviously the old one doesn't have the user data, as those a pushed to the new one after the $session->fork() operation.

It is most strange, and it has me puzzled.  Then I am new to Joomla development.

On Wednesday, 9 November 2016 10:06:18 UTC, Stephen Palmstrom wrote:

[Stephen Palmstrom]

Further on this:  The data flow is as follows:

1. Attempt to log in with a guest user and any password.
2. Jooma authentication fails, obviously,
3. Office 365 authentication kicks in and goes out to get login details from the Microsoft login page returning to a custom script that.
1. Builds the information that a Joomla login would be POSTing to the Joomla application.
2. Replaces the guest user with the Joomla user mapped from then Microsoft user.
3. Adds the Microsoft token etc. for use later.
4. Calls the Joomla application
4. The Joomla application now runs again, and this time, the Office 365 login succeeds because it recognises the user's Microsoft login status, and it returns a successful login status.
1. The Joomla OnLogin routine runs and does the session forking.
5. The Joomla application runs again, as you would expect after a successful login.  It is at this point that it, when running under Edge or IE, that the old, not new session variable is picked up.

This what is most puzzling - the problem does not occur on authentication/login, but afterwards.  I have been unable to see where the session variable is stored - NetBeans/XDebug doesn't seem to show it, thought I wonder if the ID is held as a cookie, there is cookie variable holding the session name and ID which, in the Edge environment doesn't change.  I haven't managed to find out where Joomla gets the session variable either.

[Stephen Palmstrom]

Further on this - in Chrome, the cookie session variable gets updated, with Edge, it does not!

[Stephen Palmstrom]

On further investigation, it seems that the correct cookie is sent to the browser, but it still retains the old value.  This is most strange.

On Wednesday, 9 November 2016 10:06:18 UTC, Stephen Palmstrom wrote: