Multiple WWW-Authenticate headers

[Fasih]

RFC allows a server to respond with multiple WWW-Authenticate header (​http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47).

"User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters."

However nginx defines WWW-Authenticate header as an ngx_table_elt_t in the ngx_http_headers_out_t struct as opposed to an ngx_array_t like other allowed repeated value headers.

I am using nginx as a reverse proxy. The upstream sends two WWW-Authenticate headers with different realms. I was processing the www_authenticate header field and hadnt realized that it was legal to send multiple WWW-Authenticate headers.

One e.g. for a valid real-world use:

​http://stackoverflow.com/a/15894841/1597813

[David Carlier]

This is my very first contribution, please do not be too severe. so I ve updated the ngx_http_request_t struct and updated module consumers as well. I have tested with mdounin unit tests and it looks ok.

[Maxim Dounin]

Please see ​this thread and ​this message in particular. As suggested, just changing WWW-Authenticate to array_t looks wrong.

Note well that the patch suggested doesn't allow to intercept 401 errors from upstream with multiple WWW-Authenticate headers. And this looks like the only practical problem with multiple WWW-Authenticate headers.

Please also see ​http://nginx.org/en/docs/contributing_changes.html.

[gerrieg@…]

Are there any plans to support multiple WWW-Authenticate headers soon?

In our company we want to switch the IIS servers to NGINX, we are using the auth_request_module and we developed a authentication server that sends a Negotiate and a Basic WWW-Authenticate header. But only the first one arrives at the client.
We tried to send the two challenges in one header, but the clients do not understand this.

Now we are blocked, so any chance to implement this?

[kipras@…]

We've hit this issue as well. Just wondering if this is this planned to be implemented sometime ?

[DenverJ@…]

We have also hit this issue with the auth_request module trying to use an intranet authentication server that sends multiple WWW-Authenticate headers. A real blocker!

[Maxim Dounin <mdounin@…>]

In 8036:f739c8142fb2/nginx:

Upstream: multiple WWW-Authenticate headers (ticket #485).

When using proxy_intercept_errors and an error page for error 401
(Unauthorized), multiple WWW-Authenticate headers from the upstream server
response are now properly copied to the response.

[Maxim Dounin <mdounin@…>]

In 8037:8272c823a7d0/nginx:

Auth request: multiple WWW-Authenticate headers (ticket #485).

When using auth_request with an upstream server which returns 401
(Unauthorized), multiple WWW-Authenticate headers from the upstream server
response are now properly copied to the response.

[Maxim Dounin <mdounin@…>]

In 8038:711737177b77/nginx:

Multiple WWW-Authenticate headers with "satisfy any;".

If a module adds multiple WWW-Authenticate headers (ticket #485) to the
response, linked in r->headers_out.www_authenticate, all headers are now
cleared if another module later allows access.

This change is a nop for standard modules, since the only access module which
can add multiple WWW-Authenticate headers is the auth request module, and
it is checked after other standard access modules. Though this might
affect some third party access modules.

Note that if a 3rd party module adds a single WWW-Authenticate header
and not yet modified to set the header's next pointer to NULL, attempt to
clear such a header with this change will result in a segmentation fault.

[Maxim Dounin]

Fixed, thanks to all involved.

Note that 3rd party authentication modules have to be modified to be compatible with the new approach of handling multiple WWW-Authenticate headers.