Jira tasks from Confluence are not visible after directory change

[Кирилл Самсонов]

Hi

Previously, we used Jira accounts in the Jira Internal Directory, but due to security issues, we had to change them to domain accounts. Since mass transfer was not possible, the scheme was used:

1. A new "user-new" entry was created for the "user" in the new directory

2. It indicated the same groups as the old user.

3. All tasks of the old user were transferred to the new one.

4. The old account was renamed to "user_old", the new one to "user"

After that, there was a problem that when using Confluence, no tasks from Jira became visible. The error text "the Jira problem does not exist, or there are insufficient rights to view it" and "The Jira links could not be displayed. Perhaps the problem does not exist, or there are not enough rights to view it"

At the same time, the accounts have an absolutely identical set of rights and groups. The problem is relevant for all migrated accounts

[Кирилл Самсонов]

I removed the old user's access from Conf to Jira, after that the new user had a request for authentication from Conf to Jira and after that the problem disappeared! The last question is how to do it massively for old users now

[Radek Dostál]

Application Links use OAuth, more on that here: https://confluence.atlassian.com/adminjiraserver0813/using-applinks-to-link-to-other-applications-1027137531.html

Have you only changed the accounts in Jira, or also Confluence?

Can you show us the application link setup from both applications? (You can obfuscate urls or ids, just want to see the settings.)

Lastly, can you tail atlassian-confluence.log, load a page resulting in the error, and see if it throws anything in the log? If the problem is what I think it is, there should be a stacktrace in there. I'd expect one of these errors https://confluence.atlassian.com/kb/oauth-troubleshooting-guide-719095274.html#OAuthTroubleshootingGuide-Errormessagesinthelogs

And finally, if you try to create a new 'jiraissue' macro - does it work? Does it let you authorize the AppLink, or does it simply throw an error with no authroization prompt at all?

[Кирилл Самсонов]

We changed accounts in jira and then they migrated to confluence

I looked atlassian-confluence.log, but I didn't find any mention of the problem there.  I didn't even find a mention of the user at the time when he had an error

[Radek Dostál]

Thanks, this narrows things down a little bit. So as far as I know this should mean that Confluence keeps 'oauth' tokens in it's database for each user. My suspicion is that the tokens are now stale because they are - for the lack of better words - using "user_old" Jira counterparts.

We changed accounts in jira and then they migrated to confluence

Could you elaborate what this means?

Here's my theory, previously you would have username "bob" in Confluence, with his "bob" username in Jira.

Bob logs into Confluence for the first time, and then sees a macro from Jira with "Authorize" prompt.

Bob clicks it, logs into Jira, thus Confluence stores a token for Bob.

This token will be used to fetch Jira data under the account Bob logged into Jira with.

Later, Jira username "bob" was changed to "bob_old" - this technically did not invalidate the token in Confluence, rather, Confluence is still trying to use this token, but Jira is (rightfully so) saying "sorry but you no longer have access to this resource, according to your account bob_old".

And there we are getting to the "but hey, same username!?", well, I would assume the tokens are stored on a "userkey" basis (and I mean, userkey is basically the same as account id as far as uniqueness goes). So even though you created the same username "bob", it's unique userkey is different. They are entirely different user accounts to Jira after all.

Does this sound like this could be the case so far? Because if so, then I think you would need to manually remove all OAuth tokens from Confluence DB (there is an sql query to delete them), and then each user would have to authorize their AppLink again to re-create the OAuth token. Only this time, it would use their "new" Jira accounts.

This of course is not ideal since you would want to shutdown, backup, delete, start, and then the users would be inconvenienced to authorize the app link.

However, in the case that you have also switched Confluence user directory to ldap, and you now have exactly the same user directory, thus exactly the same userbase, then you might be able to switch to OAuth with Impersonation - which should, in theory, not require the users to authorize the AppLink connection - the macros should work for them, provided they have the same username in both Confluence and Jira.

I'm also curious right now if there is a way to confirm the OAuth token theory on a local scale (e.g. just 1 user) before deciding to do the big bang. There must be a way to link the token back to the Confluence user, so you should be able to find just the one token for e.g. your user, try to delete it, and then see if Confluence asks you to re-authorize and if things will work.

The sad part is I don't have a single instance which doesn't use OAuth with Impersonation already (have been around impersonation for years now..), so I can't test this or look around the db myself, or try to simulate your situation to confirm my idea.

[Кирилл Самсонов]

Could you elaborate what this means?

Maybe I wrote incorrectly, but I wanted to say that we only worked with Jira users

Yes, I also had a theory, the same as you

I will try to remove the OAuth token in the Conf database from one user and then write here about the results

[Кирилл Самсонов]

I didn't find where this token is in the database, but with one of the users with this problem, we went to Confluence in his profile - settings - opened the list of oauth access keys (and there were 2 of them, apparently the old and the new). Both were revoked and this key was re-created from Jira - it didn't help :(

[Кирилл Самсонов]

Now I noticed that if the user goes to the "profile" - "tools" and then "view oauth access tokens". there we see the inscription "applications do not use your account to access jira data"

[Radek Dostál]

Unless somebody here can provide a safe way to flush/refresh the tokens, then I would advice you to get in contact with Atlassian support and explain what you did with user directories to them.

I can't reproduce your problem to confirm the way forward, but I generally suspect the old OAuth tokens - again though, I don't know the exact steps to do here without being able to test and confirm it, or dig around the logs/tables myself.

[Кирилл Самсонов]

Radek, thank`s! 

I described my last problem in the upper answer