Webhooks need to bypass user permission checks

[cconard96]

The Webhook feature currently makes requests for the related data through the new API and uses the current logged in user. In most cases, this isn't an issue since whoever creates/updates something also has the ability to view that item. When webhooks get triggered from a Crontask though, the current user may be too low privileged, in another entity, or there may not be any user logged in at all in the case of externally triggered tasks.

This issue was noticed with tickets created from collected emails.

[cedric-anne]

Unless I miss something, there is no "current user" in a crontask context. What user is used then?

[cconard96]

If no user is logged in, no user is used. The requests to the API are made directly through the router rather than making HTTP requests through curl or Guzzle. The only "authentication" that is done is through InternalAuthMiddleware where it sets the client info manually or causes the authentication process to fail if there is no logged in user.

[orthagh]

cf !35208

I don't know if we need a bypass (maybe yes) but we need more and more cli executions and rights checkings are locking too much in this context.
more example, already identified execution of workflows. We need this before 11.0 release.

I am not sure, but as an alternative to opening the gates, we may use the SYSTEM_GLPI user for that instead, and check if can have full rights for him (it may already be the case). It will help also identify actions in logs.

[cconard96]

I had two ideas when I was made aware of the issue yesterday:

1. Use the system account as a sort of "Global Administrator". We still block actual logins with this account and prevent assigning profiles, but have a method to manually switch to a session for it and automatically grant permissions over every entity and all rights in the session itself. This would only work in separate requests (both workflows and webhooks make HTTP requests to the GLPI API).
2. For webhooks at least, we let the administrator choose the user account that will authenticate with the GLPI API for the data via actual HTTP requests.

For workflows, we could try forcing all permission-dependent interaction through the GLPI APIs or create a bridge in the GLPI core that lets that specific feature bypass permission checks.

[orthagh]

CF #14652

Edit, 👆🏽 this can directly close the subject.

[orthagh]

With only webhooks in mind, as it's an urgent matter, what is the best solution:

• bypass callable (from Add ability to bypass right checks #14652)
• login as system user
• both?

@cedric-anne reminded Tuesday me he is in favor of the bypass mechanism as proposed in the PR.
We need to find a solution for our partner.

[cconard96]

The callable from the PR doesn't affect group/entity checks. I am not sure having webhooks created during cron tasks will work correctly with only bypassing regular permission checks.

System user login in the new API would need some thought as to how we implement it without letting regular users gain access to it. Logging in as the system user during external cron tasks could be possible but it doesn't affect anything during a regular user session.

Setting a flag to skip permission/visibility checks in the new API's search code could cover most cases, but at least any checks in mapped properties would still be enforced but at this point there are no permission/visibility checks done in these.

I don't have any other ideas right now for ignoring user permissions/entity/groups/etc.

[trasher]

@cedric-anne reminded Tuesday me he is in favor of the bypass mechanism as proposed in the PR. We need to find a solution for our partner.

As I said to Cédric in our internal channel, if #14652 solves current webhook issue, it's OK for me.