Authentication guide for MageBridge

When working with two applications which both contain user-records, it is important to know how these applications interact with each other when dealing with users. For instance if an user logs into Joomla and that user does not exist yet in Magento, should this user-record be automatically created in Magento? This whitepaper explains more about how MageBridge deals with users.

Email-addresses as usernames

Both Joomla as Magento have a database containing users. With Joomla, users are users. With Magento, they are called customers. Magento customers are identified by their email-address, while with Joomla the username can be anything. Instead of messing around with manual configurations, we have decided to follow the Magento logic and say that every user can be identified by his or her email-address, and there for we need to use the email-address as username.

This can create problems as soon as you create an user in Joomla (where the username can be anything) and then try to synchronize the user to Magento. We recommend you don't create users through Joomla, but create them in Magento instead and let MageBridge auto-create the user on the other end. However if you create a Joomla user, MageBridge will create a similar Magento-user as well. Also if a Magento customer is created, that user will be created in Joomla as well. If you have a Joomla user or Magento customer created before MageBridge was installed, again MageBridge will automatically create an user in the other application if needed.

Even if you choose to use Joomla usernames different than email-address, things will still work around. Still the email-address will be used as username for Magento users. If you change either your username or your email in Joomla, MageBridge will check with Magento if the new value doesn't conflict with any other existing value.

To simplify the things above a bit: If you use email-addresses as usernames, you're completely on the safe side. If you don't, there's a fairly good chance that MageBridge still supports this but it's not completely safe.


When an user logs into Joomla, Joomla uses authentication-plugins to check whether the filled-in username and password match. By default, Joomla has its own authentication-plugin, while MageBridge adds its own authentication-plugin. All plugins can be reviewed by navigating within the Joomla Administrator to Extensions > Plugin Manager and selecting "Authentication" in the top-right selectbox.

By using authentication-plugins Joomla allows for external authentication-procedures to be used - for instance Joomla also ships with plugins for LDAP and OpenID. MageBridge adds another plugin that allows for authentication to be checked against the Magento user-database.

Very important for you to know is how the plugins deal with authentication. As soon as an user tries to login, its username and password are sent to the Joomla application and the authentication procedure starts. In this procedure, Joomla fetches a list of all authentication plugins (ordered by the ordering-field in the database) and asks the first plugin to authenticate the user. If the plugin returns a positive answer, the procedure stops and the user is authenticated. However if the plugin returns a negative answer, the procedure does not stop but continues to the second plugin, and so on.

Empty password in Joomla!

Also important to know is that if an user has an empty password in Joomla (that means, in the database-table jos_users the password-field has no value), the user is valid within Joomla! (for instance when dealing with authorization), but authentication will always fail - that's logical, because there is no password to authenticate with.

In a default MageBridge environment, Joomla will first try to authenticate an user against the Magento database. If that fails, it will fall back to Joomla. But if the user has a record in Joomla but it's password-field is empty, authentication will fail and the user is unable to login.

MageBridge solves this by keeping everything in sync. As long as MageBridge is running, it will detect changes being made in either Joomla or Magento, and copy those changes to the other side. This also applies to passwords - as soon as you login to Joomla your password is synced with Magento, and vice versa. (Note that this is not true when running Magento as a stand-alone application, because MageBridge is than not fully functional.)

Single Sign On (SSO)

One of the more complicated features of MageBridge is Single Sign On. When talking about this subject, Single Sign On (SSO) is often confused with Single Sign In (SSI). The latter, SSI, is just the feature that one can use the same user credentials in both Magento as Joomla - this is already discussed above. Single Sign On goes a step further by allowing you to login into both applications simultaneously.

Though this sounds very cool, it could be very confusing for a customer. When a customer enters the webshop under the Joomla site, there is no reason for the customer to be redirected to the Magento side. However, SSO does work. There's only one downside here: Because in the MageBridge settings in Magento you are not asked to configure the Joomla host, in the stand-alone Magento application the bridge does not work. And there for SSO from Joomla to Magento is working, but from Magento to Joomla. Feel free to post your comments on the Yireo forum on this - we're still discussing introducing this feature.

Single Sign On is implemented in MageBridge by using HTTP-redirects. When a customer logs in, first the authentication is dealt with through the bridge. But the bridge is built up between Magento and Joomla. The key to SSO is getting both browser-sessions in sync. To do this, the browser is redirected to the Magento website temporarily - there MageBridge authorizes this request and logs in the user as requested. Then, the browser is redirected back again to Joomla where the Magento session is registered within the bridge. Consequently the session between Joomla and Magento is now the same as the session between the browser and Magento.

The SSO-mechanism of MageBridge does not use cookies and works even if Joomla! and Magento are installed on completely different domains. Furthermore, it is secure and even improves the regular Magento security by preventing session-fixation attacks.

A final word: SSO is enabled through the User - MageBridge plugin in Joomla. The plugin has parameter to turn on or off Single Sign On. As soon as you enable SSO, it is very important that the plugin has the highest ordering-number, which makes it execute as the last user-plugin in a row. The reason for this is that SSO redirects the user to Magento, which means that the whole plugin-execution in Joomla stops. Always make sure the User - Joomla plugin is loaded before the MageBridge user-plugin - otherwise no one is able to login anymore.


MageBridge doesn't deal with authorization at all. Authorization - in simple words: what a person can and can not do - is dealt with by Joomla and Magento separately. As long as these rules are working properly in either Joomla or Magento, the same will (most likely) apply for the bridged result.

FAQ: Lookup option in the MageBridge Authentication Plugin in Joomla

The MageBridge Authentication Plugin has a feature to lookup emailaddresses. It is a bit of a complex feature: When someone logs into Joomla using a Joomla login box, this happens with the Joomla username. However, if someone would enter his Joomla email, the Joomla Authentication Plugin would fail, but this email could be picked up by the MageBridge Authentication Plugin to forward this login to Magento, and because Magento uses emails instead of usernames for identiyfing customers, this would still work.

Now, by enabling this lookup in the plugin settings, MageBridge will automatically translate the Joomla username into the Joomla email, so that it will be useful when authenticating to Magento. Note at this point, you will be assuming that Joomla authentication has failed already.

If you are using email addresses only as login credential, then turning this feature on has little effect. The credential is already an email address. If you are using both username as email address, then this feature is important and is best turned on.