how to configure request rate limiting by Kerberos authenticated user?

Maxim Dounin mdounin at
Thu Aug 6 00:34:52 UTC 2020


On Wed, Aug 05, 2020 at 09:21:42PM +0000, Nica, George wrote:

> We are currently using "limit_req_zone $binary_remote_addr" for rate limiting. However, some of our users are connecting from more than one IP address, using clients running on computer grids.
> We wanted to do request rate limiting by authenticated user (in addition to the existing one by $binary_remote_addr).
> Is there any way we could do request rate limiting based on authenticated user?
> We use Kerberos for authentication, using ngx_http_auth_spnego_module (
> We tried "limit_req_zone $remote_user zone=user:10m rate=20r/s;" and "limit_req zone=user burst=20;" but the key was apparently empty - all requests, from all users, were getting limited (all bunched under one key). However, interestingly, $remote_user is passed fine to the upstream using "proxy_set_header X-Forwarded-User $remote_user;"... Apparently $remote_user only works for request limiting when using basic authentication.
> Thank you for any suggestions/pointers.

The $remote_user variable is extracted by nginx from the 
Authorization header only when using Basic authentication.  The 
SPNEGO auth module tries to make it work by providing a fake 
"Authorization: Basic ..." header to nginx, but this won't work 
for limit_req because rate limiting happens before access checks 
(and so before the SPNEGO auth module adds the fake header).

If you want to limit requests based on the user name from the 
SPNEGO auth module, the most obvious solution would be to do this 
with additional proxying, so the user name will be known.

Alternative solutions include adding its own variable to the 
module, so it can be used at any time (much like $remote_user when 
using Basic authentication), or doing some clever redirect tricks 
to convince nginx to do authentication first, and then to do rate 
limiting (in another location, after a redirect).

Maxim Dounin

More information about the nginx mailing list