Switching authentication method in Confluence (5.25)
At work, we have been using our Google Apps account for logging in to Confluence and wanted to move to sharing our JIRA logins instead. Integrating JIRA logins is a cinch in Confluence. Once setup, all our JIRA users appeared in Confluence. Great. The only remaining task was to gid rid of our old Google Apps users and change the owner of all the old content to our new users. Finding a way to do this proved very difficult indeed, with zero documentation that I could find for this particular example.
What documentation there is
Here are the closest instructions I could find. Unfortunately they are out of date for Confluence 5.25 but the gist of them is still rings true and, if you waded through the many comments (I didn't), you would have found something very close to what I found to be the answer. I ended up having to figure it out for myself late at night so I thought I'd write a quick post on the method I used - hopefully it will appear in Google results for others in the same boat.
How I did it
Disclaimer: this worked for us and our setup. I cannot guarantee that it will work in your setup. All the SQL code below is for MySQL.
The method revolves around the database table,
user_key column in this table is used as the foreign key references throughout the system when tagging a user against content, attachments, etc. This
user_key is then mapped to the username of the
cwd_user table in which the user details are stored. This method simply associates the
user_key of the old username with the new username.
Usefully, the user groups association is mapped to the primary key of the
cwd_user table meaning that we can easily migrate the content without affecting a user's associated group permissions.
1. Shutdown confluence
2. Create a temporary user migration table and fill it with the migration user details
create table usermigration ( oldusername varchar(255) not null , newusername varchar(255) not null , oldkey varchar(255) not null , newkey varchar(255) not null ); -- populate the table any which way works for your scenario. The keys and usernames are those found in the user_mapping table.
3. Nullify the new user mappings
update user_mapping set user_mapping.username = Concat('tmp_', user_mapping.username) , user_mapping.lower_username = Concat('tmp_', user_mapping.lower_username) where user_mapping.user_key in ( select newkey from usermigration );
4. Map new users to the old users
update user_mapping , usermigration set user_mapping.username = usermigration.newusername , user_mapping.lower_username = usermigration.newusername where user_mapping.user_key = usermigration.oldkey;
5. Start confluence
6. In case of emergency, rollback
Stop Confluence before this and start it up again afterwards:
update user_mapping , usermigration set user_mapping.username = usermigration.oldusername , user_mapping.lower_username = usermigration.oldusername where user_mapping.user_key = usermigration.oldkey; update user_mapping , usermigration set user_mapping.username = usermigration.newusername , user_mapping.lower_username = usermigration.newusername where user_mapping.user_key = usermigration.newkey;
The documentation for this seems nowhere to be found so I can't be sure that I haven't missed some vital step here (please comment if you find that I have). However, after running the above and disabling google apps login, we were able to login with JIRA and see all our old content mapped to our new JIRA users. Once we're confident that nothing is broken, we will permanently remove the old Google apps users.
Given that all that was necessary was to switch a single mapping record for each user, I'm surprised that I couldn't find anything official on this. I'll comment on the old instructions and hopefully that can be rectified.