Limitations of Multi-domain setups in 2.0

[ShMaunder]

It has been discovered that there are limitations to the 2.0 implementation of multi-domain setups. This includes:

• Duplicate usernames between domains: Only one JUser generated and must be shared between all users; User to domain mapping must be switched off to allow all users to login; Unable to rely on SHFactory::getUserAdapter to retrieve correct user.
• Inconsistent and broken API when trying to retrieve a user from a specific domain.
• onUser plug-in events have no information on the user's domain. This means all LDAP plug-ins are unreliable in multi-domain setups. However, this will only apply to duplicate usernames.

Targeted for the 2.1 release to overcome the above:

1. Ensuring uniqueness in Joomla's user table. To achieve this, a new option to append the domain name to the end of each username. This is similar to how Active Directory users have UPN's. For example the user "fred" on domain "shmanic" would be able to login with "fred" but is saved in Joomla as "fred@shmanic". Most of the changes should be isolated to SHFactory::getUserAdapter and some entry methods in the user adapter.
2. Enforce a domain (namespace) on file configurations. In 2.0, a file configuration can be configured without a domain/namespace. This will break backwards compatibility with 2.0 and therefore how updates are handled from 2.0 -> 2.1 must be considered.
3. Plug-ins require the adapter object being passed to them in onUser events. Passing this in the method parameters is probably the best way to achieve this. Possible API BC break for any 3rd party LDAP plug-ins which I don't believe exist.

Further considerations:

• The effect of having different usernames in the Joomla database has had limited testing so far. Hopefully the only user facing view of this username is in Joomla's user manager. Might be worth testing some popular 3rd party extensions with this approach.
• Group adapters (feature in 2.1) will follow this exact same approach. So abstracting and reusing code from the user adapter implementation should be considered.
• Migrating current users to this new format might be an issue. Changing usernames should be done through Joomla's API and not a direct database query meaning listening 3rd party extensions can update any username maps they have.
• Changing domain names would become a big issue with this approach. It would be easier to disable this functionality.

[ShMaunder]

Progress so far:

• Group adapter implementation pushed to 2.2 due to the amount of code change already in 2.1.
• File configurations now use a unique ID in the class name to represent a configuration. They also implement the domain field as an attribute. Would be a lot cleaner and easier to maintain BC by using XML. Backwards compatibility is broken from 2.0. Prevent updater from updating current 2.0 sites and present an informative error with solutions on the situation is the best way forward.
• The domain append option is partially implemented, but have found other options to maintain uniqueness. Will be allowing the Joomla user ID attribute to have a mix of fixed strings and LDAP attributes. Also the requirement for the input in the user query to match the Joomla username has been removed which allows a greater amount of flexibility (i.e. what the user logs on with doesn't need to match the Joomla username).
• There are some BC issues with LDAP plug-ins due to the new adapter identifier that is passed to some specific events.
• May also implement a SHConfig registry entry for adapter.domains holding a JSON for Domain:Name which should help to reduce 1 or 2 SQL calls in the new SHFactory::getAdapter. This registry entry will be populated by the component and ldap cron.