Checking if user is Jira admin (or has some other global permission) from server

Hi, I want to secure some endpoint in my Connect app by checking if current user is Jira administrator. The codename of corresponding global permission is “ADMINISTER” (got it from /rest/api/2/permissions). I’m trying to use /rest/api/2/user/permission/search with combination of account id, the permission and project / issue key but it works only for project permissions - when I check for global permissions the endpoint says that “Invalid permission name specified”.

Does anyone encounter such a problem and / or found a solution? Is there any other way to check if given user is Jira admin? I cannot use context query string parameter because, as I mentioned, I’m not trying to secure a Connect module, I’m trying to secure custom REST endpoint on my server.

Any help appreciated.

6 Likes

Hi @maciek ,
Have you tried using Get my permissions API?

The query /rest/api/2/mypermissions?permissions=ADMINISTER should return indication whether the user is an admin or not.

HI @jtrzebiatowski

Unfortunately, this endpoint requires ACT_AS_USER scope.

In some other thread, we agreed with @kkercz that ADMIN scope should be enough for apps to check users permissions. That is because Jira UI allows administrators to check other users permissions.

ACT_AS_USER is more for acting as users (adding comments, logging work, ets.), while checking permissions is more ADMIN type of work.

I hope you guys can fix this hole because we are not able to protect our app properly without decent permissions API.

Thanks,
Jack

1 Like

No updates on that?.. That’s frustrating. The app should be able to check permissions and groups without admin and act_as_user permissions. Both have too much power with no good reason for that. That’s just insecure and looks ridiculous since now Atlassian pushes Cloud and Security.

1 Like

@kkercz are you aware if there are any plans to allow apps with ADMIN scope checking if user is global admin?

1 Like

@maciek, did you raise maybe an ACJIRA request?

We’re having to move a lot more of our api calls to be ACT_AS_USER for read only access due to the changes that’s happening to the rest api. Ideally that scope would be broken down into more levels (ACT_AS_USER:read, ACT_AS_USER:write etc).

It sure would be nice if we could get more scopes in general though (such as “request_permission_levels_for_any_user”.

/Daniel

3 Likes

I’m afraid I don’t know of any near-future plans in this area. But this is definitely a valid feature request, so I would suggest creating a ticket in ACJIRA for us to properly track it and gauge interest.

In addition to that, let me say that we are aware that the current set of scopes available to apps is too coarse-grained and does not allow apps to properly define their intent to customers (e.g. if the app wants to check if someone is a global admin, then perhaps it shouldn’t have to declare scope “ADMIN”, but – maybe – “CHECK_PERMISSIONS” instead). We are hoping to improve this situation eventually, but it’s too early to provide any details or timelines.

4 Likes

I raised an issue in ACJIRA: https://ecosystem.atlassian.net/browse/ACJIRA-2107

1 Like

You can add ?user_is_admin={condition.user_is_admin} to your url in the app descriptor and then you can check this parameter value in your app.

See https://developer.atlassian.com/cloud/jira/platform/context-parameters/#inline-conditions

1 Like

@raimonds.simanovskis that’s true, but I need to secure custom REST endpoint that is provided by my app’s server, so I can’t use descriptor here. I can pass the query string param to the frontend, but I want to secure backend as well so that any malicious users won’t be able to use my REST endpoint.

3 Likes

@raimonds.simanovskis yes it’s possible solution. But this is not appliable for app’s API. So I have to introduce some kind of sessions to be ensure that my API called within context with admin user. It’s ok but it looks like unnecessary complication.

2 Likes

You could use the GET /rest/api/3/user/groups endpoint which you can call with an accountId and verify the user being in one of the 3 admin-groups.

@thomas1 unfortunately it’s not an option. Users can tweak product access for different groups. So it possible to setup the instance where site-admins (or jira-administrator or anything else) will not have access to administer pages at all

3 Likes

I’d love to see this new CHECK_PERMISSIONS scope, but even then, the user search API is limited if a user has all of the (project) permissions.

I’ve raised https://ecosystem.atlassian.net/browse/ACJIRA-2115 to ask for accessing a user’s permissions in the Jira Expressions API.

1 Like

Hi
I would like to share some good news with you. :tada:

We’ve finally extended the functionality of POST /rest/api/3/permissions/check by allowing checks of other user’s permissions by passing the account ID to the request. Administrator permissions are required.
More details at https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-rest-api-3-permissions-check-post

I hope this will be a viable solution for your problems with checking users’ permissions and I would be more than happy to hear your feedback!

9 Likes

Hi @MaciejStanuch,

it is indeed a very good news, thanks for extending this endpoint! I checked it and it works like it should.

The only problem I see is that it’s not possible to check permissions of anonymous users. Are there any plans to extend this endpoint so that it covers also this use case?

Hi, I would like to propose another solution to the problem that most of the marketplace vendors have, i.e. authorization of the custom endpoints in ac-express and ac-spring-boot frameworks. However, it would require Atlassian help.

I have described it here

What we really need is a secure way to check whether our endpoint is called by a user with the same roles that are defined by conditions used in connect modules in atlassian-connect, i.e. user_is_admin, user_is_project_admin, user_is_logged_in.
Basically, we want to restrict our endpoints in the same way we restrict access to the pages/panels where they are supposed to be used.

We could have that information in a token received by AP.context.getToken(). This token is sent to app’s server anyway and it contains context claims already, e.g. issueId, accountId, etc. This token is decoded on server side, context claim would need to be exposed by ac-express, ac-spring-boot, but this is already happening: https://ecosystem.atlassian.net/browse/ACSPRING-88

It would be secure and wouldn’t force us to declare scopes that we don’t need, what is more it, calls to mypermission would no longer be needed. Right now, most vendors avoids securing their endpoints being afraid that it will impact apps performance. 1 more call to Jira on each endpoint. You could say permissions can be cached, but that solves 1 problem and at the same time introduces many more.

At the moment there’s the possibility of checking anonymous user permissions by making a request as an anonymous user without providing an account ID. I don’t know about any plans of extending it any further at the moment.
I hope that solves your problem, if not I’ll try to look some more into it.

@MaciejStanuch you’re right, I was able to get permissions for anonymous users but I had to omit both accountId in the request’s body and Authorization header. When the header was present but no accountId then returned permissions were for user / addon represented by Authorization header.

2 Likes