Return HTTP Status 403 on Access Denied Error

[rbd]

Hi Zammad Community,

I am currently evaluating Zammad for my organization as a replacement for OTRS. I’m really pleased a lot with the experience Zammad offers but ran into an issue with HTTP response codes when access to resources or actions is denied.

We are running all our internal applications behind an existing HTTP authentication which is integrated with our primary ACL, sort of an Intranet setting. We want to avoid to have any application handling potentially sensible user-related information to be openly accessible from the internet if this is not really necessary.

While this setup seemed to work nicely (especially with the recently added SSO feature using REMOTE_USER from the webserver to automatically log in already authenticated users) we experienced some issues quickly, because Zammad will always return HTTP status 401 when there is any sort of authentication or authorization error.

Expected behavior would be to return 401 when authentication is insufficient (e.g. login is required, but client is not logged in) and to return 403 on authorization errors (e.g. access to a resource is denied).

Zammad returning 401 will break HTTP authorization as the browser will invalidate the authorization credentials when it encounters status code 401, thus displaying the HTTP login box to the user again.

A typical situation during which this gets very annoying is changing a ticket’s group to one which the user only has create permission for, so they won’t be able to access the ticket any longer after it has been moved. This sometimes leads to several requests returning 401 after the move. Each time the user has to provide their credentials for the HTTP login again.

My suggestion would be to internally differentiate between ‘not authenticated’ and ‘not authorized’ with two separate exceptions (contrary to only having one ‘NotAuthorized’ exception) and give the system administrator the choice whether or not Zammad should return 403 instead of 401 on ‘not authorized’ errors. Especially considering the SSO functionality using HTTP auth, running Zammad behind HTTP auth might become more common in the future.

Any thoughts on this topic? Am I maybe missing something which makes 401 obligatory?

Cheers,
Leif

[MrGeneration]

@anon29869905 might correct me here, but displaying the login mask is in my opinion a desired “fallback”, as your authentication might fail for whatever reason (no matter if you just don’t have access because you got no account or your login data is invalid).

If we’d jump on a 403 page without showing the login page, the user would e.g. have to click a link or take other actions in order to get back to the login mask to try to log in again.

Just my thoughts. Personally I don’t see an issue returning error 403 which allows you to more granulary check your logs and stuff, but the login mask should always get displayed if your not logged in (and not trying to register or reset your password).

But that’s just my opinion.

[anon29869905]

Hey Leif! Glad you like Zammad and plan to move from OTRS. Your expectations regarding HTTP status codes are valid and we noticed them ourselves just recently. We have a larger refactoring of the internal authorization program logic and structure ready to get merged right after the upcoming 3.3 release (next week). However, this is currently only a refactoring of the architecture but not of any external factors. The good thing is that it will allow us to switch to the proper HTTP status codes for authorization errors. We haven’t thought it completely through yet because we have to think of other applications as well because this will be a behavior change. Anyhow, I can imagine that we will be able to make the change with Zammad 3.4 or 3.5. I’ll keep you updated!