Any way, via REST API, to mark an issue as approved by someone other than the authenticated user?

[Philip Colmer]

We're trying to develop some automation which, as part of its workflow, needs to occasionally mark issues as approved but on behalf on someone else.

It looks like this isn't possible but I thought I'd ask here as a double-check ...

Calling the "Answer Approval" API marks the issue as approved by the authenticated user. The documentation says "The approval is assumed to be owned by the user making the call." which sort of suggests that there is a way to mark the approval as owned by someone else but the API documentation doesn't suggest how.

We've tried editing the custom field that holds the approval data so that the "approverDecision" value for a different user is set to approved but that doesn't seem to write back, even though we don't get an error.

I appreciate that this may be by design. I was just wondering if there was something I hadn't thought of that might allow me to achieve what I'm after.

[Philip Colmer · Accepted solution]

We've solved this, in the end, by installing a Jira app that doesn't really do anything other than store the app's credentials. We then use those Connect app credentials to create a new "run as" JWT for the user we want to impersonate.

[José Henrique Lincoln Da Fonseca Felizardo]

Hey @Philip Colmer , can you provide more details about how do you solve this issue? Your environment is JIRA Cloud? Your team create this Jira app? I have same issue here and need to help to solve. 
Thank you!

[Philip Colmer]

Hi @José Henrique Lincoln Da Fonseca Felizardo 

I wrote a very small Python script which gets deployed to AWS as a Flask app. The script implements routes for:

/atlassian-connect.json - returns the contents of the static configuration file

/events/installed - checks that the authorization header is valid, retrieves the base URL, oauth client ID and shared secret from the payload and stores it in an AWS secret.

/events/uninstalled - checks the authorization header is valid, retrieves the base URL from the payload and stores that in the AWS secret with None as the client ID and shared secret.

The configuration file has a name, description, key, base URL for the Flask app (so you have to deploy it to get the base URL then update the config file and deploy again), vendor, authentication type, scopes (important - READ, WRITE, DELETE, ACT_AS_USER), api version and lifecycle - which specifies the installed and uninstalled routes.

That then gets published to Atlassian Marketplace as a PRIVATE application. Do not do anything other than a private app for this.

So, at the end of all that, you should have an AWS secret that contains a client ID and shared secret ... so you can now have code running elsewhere that retrieves that and makes the appropriate calls to the Atlassian API to impersonate a user and get a JWT as if they were that user.

Hope that is enough but do ask for more clarification if you need it.

Regards

Philip

[Deleted user]

Hi @Philip Colmer ,

Could you help describe the mechanism in more detail? I'm a bit lost at it, so you create another separate service to do the impersonation? While the REST API for approval is being executed in another app?

[Philip Colmer]

@[deleted] 

So what happens is we creating a "dummy" app - it really does nothing at all other than get registered in a Jira instance. The permission scopes for the app include ACT_AS_USER, amongst others.

When the app is registered, the JIRA process for registering the app provides the app with some API keys. The Python script that is handling the app registration then stores those API keys in AWS Secrets Manager.

*Then* in our main code where we want to call a Jira API *as if we were someone else*, we use those special API keys to impersonate that person. That gives us a new security token that is *then* used to call the Jira API. The token makes it look as if that person is making the call.

I hope that is a bit clearer now.

User impersonation for Connect apps (atlassian.com) for reference.

[Deleted user]

Thanks for the brief @Philip Colmer , another question from me:

When you said storing the credential on the AWS Secret, did you do it for only a specific bot user, or all possible users?

If I need to impersonate the approval from arbitrary users, thus I need to trigger the dummy app every time I need to act as them? Do I need to retrieve additional steps/approval on Jira from the related person to act using their name?

thank you

[Philip Colmer]

When you said storing the credential on the AWS Secret, did you do it for only a specific bot user, or all possible users?

I'm not sure if you are asking who can use the credentials from AWS Secret, or who are we trying to impersonate.

The credentials can be retrieved by anyone who has been granted access via the AWS configuration. In our case, we have some middleware code that handles impersonating users and getting the impersonated token.

In terms of who we impersonate, it could be anyone with an account on our system.

If I need to impersonate the approval from arbitrary users, thus I need to trigger the dummy app every time I need to act as them? Do I need to retrieve additional steps/approval on Jira from the related person to act using their name?

No, you do not need to trigger the dummy app every time. The app itself really does nothing. Absolutely nothing. It is the initialisation code for the app that saves the credentials away ... so, all you have to do, is fetch those credentials when you want to impersonate a user, call the Atlassian API and you then get the impersonation token.

No, you do not need to retrieve additional steps or approval. It just works.

Hope that helps.

[Joseph Chung Yin]

@Philip Colmer -

You may already try this, if not, take a look at the following high-level suggestion:

1) Ensure the authentication user has the necessary rights as the approver + the ability to edit the issues in your JSM project.

2) Update the issue's approver to the authentication user first, and then approve the issue at question.  At the same time, you should also add a comment to the issue for the action (meaning the new approver is approving the issue on the behalf of the original approver assignee).

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Technology Applications Team

Viasat Inc.

[Philip Colmer]

Thanks for the suggestion. We had considered this as a "last resort" option. We're trying to keep the data as clean/accurate as possible and, unfortunately, posting a comment to explain who really did the approving isn't as clean as we would like.

This is for an internal-only application so I'm now giving some thought as to whether or not we can implement a minimal Connect app and use the credentials from that to go through the process of impersonating the original user. But that is not for this forum - I'll post it over on the developer community.

Thanks, though.