Welcome! Log In Create A New Profile

Advanced

WWW-Authenticate in 200 OK response

Posted by Nica, George via nginx 
Nica, George via nginx
WWW-Authenticate in 200 OK response
September 14, 2018 11:10PM
I am currently working on a multi-tier application, trying to use nginx as load balancer.
The issue is that nginx seems to be adding WWW-Authenticate in the 200 OK response after the Kerberos authentication has taken place, which confuses the client. (The client could potentially ignore it, but that's possibly another issue.)
Not sure this is expected... Any suggestion on how to avoid or work around this?

[2018-09-14 14:46:14.471] root INFO: @@@@@@ Connecting to: 'http://host1:39609/url1'
send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\n\r\n'
reply: 'HTTP/1.1 401 Unauthorized\r\n'
header: Server: nginx/1.14.0
header: Date: Fri, 14 Sep 2018 18:46:14 GMT
header: Content-Type: text/html
header: Content-Length: 195
header: Connection: close
header: WWW-Authenticate: Negotiate
header: WWW-Authenticate: Basic realm=""
header: Access-Control-Allow-Credentials: true
send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\nAuthorization: Negotiate YII........................ AghEw==\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Server: nginx/1.14.0
header: Date: Fri, 14 Sep 2018 18:46:14 GMT
header: Content-Type: application/json
header: Content-Length: 430908
header: Connection: close
header: WWW-Authenticate: Negotiate YI .....gA==
header: WWW-Authenticate: Basic realm=""
header: Set-Cookie: session=ey...ZW4; HttpOnly; Path=/
header: Access-Control-Allow-Credentials: true
[2018-09-14 14:46:14.779] client_http_auth CRITICAL: GSSAPI failed!

Best regards,
George

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Maxim Dounin
Re: WWW-Authenticate in 200 OK response
September 15, 2018 01:30AM
Hello!

On Fri, Sep 14, 2018 at 08:59:16PM +0000, Nica, George via nginx wrote:

> I am currently working on a multi-tier application, trying to use nginx as load balancer.
> The issue is that nginx seems to be adding WWW-Authenticate in the 200 OK response after the Kerberos authentication has taken place, which confuses the client. (The client could potentially ignore it, but that's possibly another issue.)
> Not sure this is expected... Any suggestion on how to avoid or work around this?
>
> [2018-09-14 14:46:14.471] root INFO: @@@@@@ Connecting to: 'http://host1:39609/url1'
> send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\n\r\n'
> reply: 'HTTP/1.1 401 Unauthorized\r\n'
> header: Server: nginx/1.14.0
> header: Date: Fri, 14 Sep 2018 18:46:14 GMT
> header: Content-Type: text/html
> header: Content-Length: 195
> header: Connection: close
> header: WWW-Authenticate: Negotiate
> header: WWW-Authenticate: Basic realm=""
> header: Access-Control-Allow-Credentials: true
> send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\nAuthorization: Negotiate YII........................ AghEw==\r\n\r\n'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Server: nginx/1.14.0
> header: Date: Fri, 14 Sep 2018 18:46:14 GMT
> header: Content-Type: application/json
> header: Content-Length: 430908
> header: Connection: close
> header: WWW-Authenticate: Negotiate YI .....gA==
> header: WWW-Authenticate: Basic realm=""
> header: Set-Cookie: session=ey...ZW4; HttpOnly; Path=/
> header: Access-Control-Allow-Credentials: true
> [2018-09-14 14:46:14.779] client_http_auth CRITICAL: GSSAPI failed!

It looks like you are trying to use "WWW-Authenticate: Negotiate"
AKA Integrated Windows Authentication, AKA NTLM authentication.

Unfortunately, this authentication scheme was designed without
following HTTP basic concepts, and authenticates a connection
instead of requests. As such, this authentication scheme cannot
work though a generic HTTP proxy. For NTLM authentication to work
though a proxy, it needs to keep connections to the backend server
alive and bound to corresponding client connections.

The best solution would be to avoid using NTLM authentication for
anything more complex than directly connected servers in
intranets.

If you can't do this for some reason, consider using the "ntlm"
directive, which is available as part of our commercial version,
see http://nginx.org/r/ntlm.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Nica, George via nginx
RE: WWW-Authenticate in 200 OK response
September 17, 2018 11:20PM
Thank you Maxim.
We are using Kerberos, on Linux. And per-request authentication, we are not trying to use session-level authentication.
Would the ntlm module help here?
We are already using spnego-http-auth-nginx-module to help with SPNego/GSSAPI.
So our issue/incompatibility seems to be between backend / nginx with spnego-http-auth-nginx-module / client. The first two sending/passing the extra headers on the response and the client getting confused by it.
As you say, nginx is a generic HTTP proxy here, so we will have to figure things out with our server / client / spnego-http-auth-nginx-module.
Are there any other suggested approaches regarding using nginx and Kerberos?

FYI, this is the output of "nginx -V":
nginx version: nginx/1.14.0
built by gcc 7.3.0 (GCC)
built with OpenSSL 1.1.0h 27 Mar 2018
TLS SNI support enabled
configure arguments: --without-http_rewrite_module --without-http_gzip_module --with-http_stub_status_module --with-ld-opt='-L /efs/dist/kerberos/mit/1.14.6/exec/lib' --add-module=spnego-http-auth-nginx-module --with-http_ssl_module --with-openssl=/home/gnica/nginx/1.14.0_2/common/usr/lib/openssl --prefix=/home/gnica/nginx/1.14.0_2/common/usr


-----Original Message-----
From: Maxim Dounin [mailto:[email protected]]
Sent: Friday, September 14, 2018 7:19 PM
To: Nica, George via nginx <[email protected]>
Cc: Nica, George <[email protected]>
Subject: Re: WWW-Authenticate in 200 OK response

Hello!

On Fri, Sep 14, 2018 at 08:59:16PM +0000, Nica, George via nginx wrote:

> I am currently working on a multi-tier application, trying to use nginx as load balancer.
> The issue is that nginx seems to be adding WWW-Authenticate in the 200 OK response after the Kerberos authentication has taken place, which confuses the client. (The client could potentially ignore it, but that's possibly another issue.)
> Not sure this is expected... Any suggestion on how to avoid or work around this?
>
> [2018-09-14 14:46:14.471] root INFO: @@@@@@ Connecting to: 'https://urldefense.proofpoint.com/v2/url?u=http-3A__host1-3A39609_url1&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=Jgva48bCRs_t1VOn7OxsyjgTLgIcBsIoFnzP9GHdtBI&e='
> send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\n\r\n'
> reply: 'HTTP/1.1 401 Unauthorized\r\n'
> header: Server: nginx/1.14.0
> header: Date: Fri, 14 Sep 2018 18:46:14 GMT
> header: Content-Type: text/html
> header: Content-Length: 195
> header: Connection: close
> header: WWW-Authenticate: Negotiate
> header: WWW-Authenticate: Basic realm=""
> header: Access-Control-Allow-Credentials: true
> send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: host2\r\nContent-Type: application/json\r\nAuthorization: Negotiate YII........................ AghEw==\r\n\r\n'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Server: nginx/1.14.0
> header: Date: Fri, 14 Sep 2018 18:46:14 GMT
> header: Content-Type: application/json
> header: Content-Length: 430908
> header: Connection: close
> header: WWW-Authenticate: Negotiate YI .....gA==
> header: WWW-Authenticate: Basic realm=""
> header: Set-Cookie: session=ey...ZW4; HttpOnly; Path=/
> header: Access-Control-Allow-Credentials: true
> [2018-09-14 14:46:14.779] client_http_auth CRITICAL: GSSAPI failed!

It looks like you are trying to use "WWW-Authenticate: Negotiate"
AKA Integrated Windows Authentication, AKA NTLM authentication.

Unfortunately, this authentication scheme was designed without
following HTTP basic concepts, and authenticates a connection
instead of requests. As such, this authentication scheme cannot
work though a generic HTTP proxy. For NTLM authentication to work
though a proxy, it needs to keep connections to the backend server
alive and bound to corresponding client connections.

The best solution would be to avoid using NTLM authentication for
anything more complex than directly connected servers in
intranets.

If you can't do this for some reason, consider using the "ntlm"
directive, which is available as part of our commercial version,
see https://urldefense.proofpoint.com/v2/url?u=http-3A__nginx.org_r_ntlm&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=V7CbzPjbpkSiNhNIaDR5P5la1fLfM5-MC6MO-KmhKj8&e=.

--
Maxim Dounin
https://urldefense.proofpoint.com/v2/url?u=http-3A__mdounin.ru_&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=56j1udQaqKDK12PhW-jGwz89_8ZMgUhTZ2tCfJDAaSc&e=

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Maxim Dounin
Re: WWW-Authenticate in 200 OK response
September 18, 2018 04:00AM
Hello!

On Mon, Sep 17, 2018 at 09:18:51PM +0000, Nica, George via nginx wrote:

> Thank you Maxim.
> We are using Kerberos, on Linux. And per-request authentication, we are not trying to use session-level authentication.
> Would the ntlm module help here?

The problem is with "WWW-Authenticate: Negotiate". As it is
specified by rfc4559, and it's screwed up: it authenticates a
connection, and hence cannot properly work through proxies. See
further details here in the RFC, and errata notice for it:

https://tools.ietf.org/html/rfc4559#section-6
https://www.rfc-editor.org/errata_search.php?rfc=4559

If you are trying to proxy to a backend which uses
"WWW-Authenticate: Negotiate", this is likely the problem you are
facing: it cannot work though a proxy. If it's the case, the
"ntlm" directive will help.

But if you are instead trying to authenticate clients on nginx side,
proxying is probably not relevant, see below.

> We are already using spnego-http-auth-nginx-module to help with SPNego/GSSAPI.
> So our issue/incompatibility seems to be between backend / nginx with spnego-http-auth-nginx-module / client. The first two sending/passing the extra headers on the response and the client getting confused by it.
> As you say, nginx is a generic HTTP proxy here, so we will have to figure things out with our server / client / spnego-http-auth-nginx-module.
> Are there any other suggested approaches regarding using nginx and Kerberos?

If the authentication is expected to happen on nginx side, this
can work - assuming the spnego-http-auth-nginx-module does the right
thing.

Looking at the spnego-http-auth-nginx-module I suspect that both
"WWW-Authenticate" headers are generated by the module. Try
looking into the module documentation and sources to find out how
to use it properly. In particular, docs suggest that

auth_gss_allow_basic_fallback off;

will disable "WWW-Authenticate: Basic", and it might make your
client happy.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login