Support/Live Chat/SUMO login
From MozillaWiki
Openfire should be able to authenticate users with TikiWiki login information, when no Openfire account exists. Additionally, there needs to be a mechanism for existing Openfire accounts to be merged with a SUMO account.
Contents
Step 1: determine requirements and draft implementation plan
Partial list of topics to discuss:
- How sumo should expose login details (a php script, direct DB access)
- How access to the php script should be controlled (key file, restrict IP, etc)
- Which data is necessary to provide to Openfire after authentication
- display name
- locale
- avatar
- group(s), for controlling access
- How to handle/merge duplicate accounts
- Who can implement what
- What timeframe can we do it in (can we add it to 1.5?)
Overview
To provide the best security, Openfire should access the users_users table directly. TikiWiki will assign a new Live Chat ID (without spaces or punctuation) to newly created SUMO users, while existing users of either Live Chat or SUMO will have to merge their accounts.
- Openfire will need read-only access to TikiWiki DB, and TikiWiki will need read-only access to Openfire DB.
- DB Configuration for both Openfire and TikiWiki will need to be extended
- IT: should Openfire and TikiWiki use a separate host/username/password for each database?
Implementation plan for Openfire (Matthew)
Implement an Openfire AuthProvider (bug ######)
This will layer TikiWiki authentication on top of native authentication.
Direct unmigrated users to migration page and refuse login (bug ######)
- Old SUMO accounts won't have a livechat_id in the users_users table, so they will need to create one on tiki-livechat_migration.php
- Old Live Chat accounts will need to be migrated into a SUMO account
Automatically add users to Openfire groups based on TikiWiki group membership.(bug ######)
- Room monitors, support team, etc
Implementation plan for TikiWiki (James and/or Paul)
Database (bug 534340)
bug 534340 (same as tiki-register.php)
- Add livechat_id to users_users table.
- NULL for existing users
- A stripped version of the username for new accounts, if available
- The old Openfire username for migrated accounts
- Make sure tiki-register.php and tiki-livechat_migration.php can access Openfire's database.
tiki-register.php (bug 534340)
- A livechat_id must be generated for each new user. Must be unique both among other livechat_id's and existing users in Openfire's of_users table
tiki-livechat_migration.php (bug 534347)
- Ask users if they have a Live Chat account and/or a TikiWiki account
- Both: Ask for both usernames and passwords. The livechat_id in the TikiWiki account should be set to the existing Openfire ID.
- Openfire only: Ask for the Live Chat password, then create a new TikiWiki account with the same credentials if possible. (If the TikiWiki username is taken, ask the user to pick another)
- SUMO only: Ask the user to log in, then create a livechat_id for the user. (Use the SUMO username if available, otherwise ask the user to create one)
- After the livechat_id is determined, delete the existing Openfire account if applicable. (Will require read-write access to Openfire DB)
- Direct the user to sign into Live Chat using the TikiWiki username and password. The livechat_id will be used for generating a Jabber ID, which has different requirements from the user name.
Cleanup and fixes
- Create a Live Chat Room Monitor group on TikiWiki
- Add live chat ID management to tiki-adminusers.php (bug 534350)
- Create a temporary script to automatically merge all TikiWiki and Openfire accounts where usernames and passwords exactly match. (bug 534351)
- After 6 months, purge unmigrated Live Chat accounts. (Matthew)
- Turn off migration feature after 6 months, when all unmigrated Openfire accounts are deleted. (bug ######)
Timeline
- Implement Openfire support in 2009Q4, but wait to deploy it until TikiWiki support is done.
- Set this up on a testing server so that TikiWiki patches can be tested. Should be done before work on TikiWiki begins.
- Schedule TikiWiki support for the next minor release after 1.5. Target for early 2010Q1.