Fake Basic Auth

Server NGINX
1

Hello,

I am new to nginx and have following problem:

Nginx should be used as a reverse proxy and configured for client
certificate authentication. Backoffice application supports basic auth
only.
Apache 2.4 solution for that kind of problems is “Fake Basic Auth” so
backoffice application gets a remote_user and password generated from
client certificate presented by user.

Example:
AuthBasicFake %{SSL_CLIENT_S_DN_CN}
%{sha1:passphrase-%{SSL_CLIENT_S_DN_CN}}
This set remote user to CN from client certifiate.

is there a similar mechanism in Nginx?

Does HttpLuaModule allow to fake a 401 authentication?

best regards
Christian

2

use ngx_lua for 401 auth example:
http://chenxiaoyu.org/2012/02/08/nginx-lua-401-auth.html

–
smallfish http://chenxiaoyu.org

3

Sorry, does not what I need:

proxy_pass http://myapache:8000;
rewrite_by_lua ’
ngx.var.remote_user = “user”
ngx.var.remote_password = “secret”
';

This should fake a 401 login but I get

2013/08/26 20:11:11 [error] 19175#0: *2 lua entry thread aborted:
runtime error: [string “rewrite_by_lua”]:2: variable “remote_user” not
changeable
stack traceback:
coroutine 0:
[C]: ?
[string “rewrite_by_lua”]:2: in function <[string
“rewrite_by_lua”]:1>,
client: 192.168.100.99, server: localhost, request: “GET /x.php
HTTP/1.1”, host: “test.example.net”

Obviously Nginx does not like any changes on remote_user

in Apache
AuthBasicFake %{SSL_CLIENT_S_DN_CN}
%{sha1:passphrase-%{SSL_CLIENT_S_DN_CN}}
set remote_user to value passwd by SSL_CLIENT_S_DN_CN and a fake
password generated from SSL_CLIENT_S_DN_CN

I need something similar for nginx.

regards
Christian

Am 25.08.2013 09:20, schrieb smallfish:

4

On Sun, Aug 25, 2013 at 08:53:57AM +0200, Christian Felsing wrote:

Hi there,

Nginx should be used as a reverse proxy and configured for client
certificate authentication. Backoffice application supports basic auth only.
Apache 2.4 solution for that kind of problems is “Fake Basic Auth” so
backoffice application gets a remote_user and password generated from
client certificate presented by user.

So, in nginx and http terms, at the point where you “proxy_pass
http://backoffice”, you also want to “proxy_set_header Authorization”
with the correct value.

The correct value is "Basic " followed by the base64-encoding of
user:pass, where “user” and “pass” are respectively the username and
password that you want the backoffice application to see.

Presumably you have a method of deriving the username from the client
certificate, and you have a method for deriving the password for this
username.

I’m not aware of a distribution-nginx-config way of doing the base64
encoding. You could try using a part of a third-party module like
Set Misc | NGINX, or perhaps you could use one
of the language modules to do the conversion. (Or you could write a
dedicated module to just do exactly what you want.)

Another option, if you have a fixed set of client certificates, could
be to use a “map” to hardcode the Authorization header value for each
certificate, and then use that variable in the “proxy_set_header” line

that would not need anything extra from nginx; and, as a bonus, whatever
method you have to turn the certificate into a username can be opaque
to nginx, so it can be as complicated as you like.

f

Francis D. [email protected]

5

On Wed, Aug 28, 2013 at 08:18:36PM +0200, Christian Felsing wrote:

Hi there,

Thank you for your hint, which solved this problem with a little bit LUA
code. If LUA code (security) tests are finsihed I will publish this code.

Good to know that you found a solution.

I guess that the outline should work in most similar cases; but the
details will likely differ each time.

All the best,

f

Francis D. [email protected]

6

Thank you for your hint, which solved this problem with a little bit LUA
code. If LUA code (security) tests are finsihed I will publish this
code.

cheers
Christian

Am 27.08.2013 00:08, schrieb Francis D.: