Security of resolver context on modules related to issue / content

Forge Forge Modules and Product Triggers
, , ,
1

Hi,

I was wondering if we could trust a resolver function context to also serve as authorization for at least the view-permission (e.g. BROWSE) on its related issue/content.

Let me give some examples, I’m having a hard time phrasing this.

  • If I have a Jira Issue Panel which calls our resolver, am I safe to assume that the user with the account ID listed in the context my resolver receives, has the permission to view the issue with the ID mentioned in the context?
  • Similarly in Confluence, if I have for example a macro where my resolver receives context indicating the user and the content, can I assume that the user is allowed to view the macro?

I think I remember at some point the extension context could not be relied upon, because it, unlike the basic context (containing the account ID etc), was not signed. And indeed, the article on the Forge resolver mentions that not everything in the context is to be trusted:

Not all of the values in the context parameter are guaranteed to be secure, unalterable, and valid to be used for authorization. See App context security for more information.

But the mentioned App context security article indicates that it is trustworthy. It mentions:

Context parameters in each resolver function are guaranteed to be secure, unalterable, and valid to be used for authorization.

I think I remember this was changed some time ago and the first article I mentioned was just not updated(?)

But even if I can trust the account ID and the issue ID for example, I want to make sure that the implication is true, that the user with this account ID can at least display the Jira issue with that ID.

Because permission checks are sometimes relatively slow (hundreds of milliseconds) and not amazing for responsive endpoints and if we could skip some of them, that would be great.

(Of course we are aware of additional security measures like always using asUser where feasible, but sometimes our apps also needs to display content that is related to a Jira issue without fetching said Jira issue)

Thanks! Cheers,
Tobi from resolution

2

I’ve done a bit more digging.

The API call responsible for fetching the context JWT (that is needed for the implementation of the invoke call) is going to /rest/internal/2/forge/context/token.

If you take one that generates a valid context JWT and change the issue ID and key in the body to something that doesn’t exist for example, I get this response

{
  "errorMessages": [
    "Issue does not exist or you do not have permission to see it."
  ],
  "errors": {}
}

This indicates to me, that there is a permission check happening before the context JWT is produced. And the content of it is what lands on the resolver as context. So therefore I would conclude that if a resolver gets called with a certain Issue ID in the context, that the calling user has at least permission to view it.

Let me know if I missed something.

Cheers,
Tobi

3

@tobitheo When I investigated something similar, I noted that the mechanism is completely different in Confluence. I did not test changing page IDs - but I would not rely on it working the same way in Confluence.