OAuth with impersonation for back-end jobs: How to authenticate, should I use ThreadLocal.setUser(...)?

Jira Development Jira Server
, ,
1

When a user modifies one of our objects in Confluence (our plugin manages requirements), we update the link titles in Jira (implemented as Remote Issue Links). So we have a queue of messages in Confluence, and a job that sends the queue to Jira every 2 minutes.

  • Should I send the messages to Jira using an administrative user? (This username could be stored in the configuration)
  • Should I send the messages using the username that created the message?

There are drawbacks everywhere, so how did you do?

  • If we send all messages as “admin” to Jira, then all edits in Jira are attributed to “admin”. Also, there is always the risk that the OAuth token of this admin expires.
  • If we send messages using the name of the user who generated the event, then if we have 200 different users editing Confluence, then we need to perform 1 OAuth request for each of those 200 users (=200 requests). Plus, some may not have a Jira login, and some others may need to perform the OAuth dance, so it’s 200 requests with 150 OAuth dances and so on.
  • I obviously don’t want to send messages to Jira using Applink’s
    createNonImpersonatingAuthenticatedRequestFactory()    , because it’s anonymous in Jira and one simply does not write code that performs modifications without being logged in.
1 Like
2

Actually, AuthenticatedUserThreadLocal.set(a pre-determined user) works to impersonate another user. So:

  • We will ask customers to save a user in their options,
  • We will always perform modifications in Jira using this user,
  • We will add a field in our JSON, so changes will be attributed in the UI to the user in that field, even though the field will have been actually modified by the technical user. We can do this because there is a very limited set of information that is modified (We only modify the title of remote-issue-links in Jira), so the inconvenience is limited.

It’s not the perfect solution (We’d prefer to use the actual user’s credentials) but the authentication is unreliable with OAuth in back-end jobs.

3

Why use a wait queue when you can send the message immediately (using OAuth with impersonation)? I see no reason to wait and the OAuth handshaking or “dance” shouldn’t be a concern. Sounds like you’re trying to over-optimize.

4

Hi Alj,

It could have been a solution, but we perform this operation when someone edits a page, so performing a request to Jira while saving a page would slow down the editing experience. Also, if the dance is necessary, there is no way to provide feedback to the user when he saves a page in the editor, so our process can’t be interactive anyway. It acts like a back-end job, whether we perform it synchronously or asynchronously.

Also, Jira may take time to respond.