stef / ngx_http_auth_sasl_module

SASL authentication module for nginx
Other
3 stars 2 forks source link

This is experimental.

It implements this RFC draft: https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl

** Dependencies If you want to build this, it expects an nginx source tree in '../nginx'

You also need https://github.com/arithy/packcc in '../packcc/' if you change 'src/http_auth_header_parser.peg'.

** Deployment

you can test with this script: https://github.com/stef/libopaque/blob/master/sasl/http_sasl.py if you have also the opaque mechanism installed from the libopaque repo. Otherwise adapt the script to use a different mechanism.

In any case the Makefile explains it all, or has pointers to more information.

** Limitations

One possible limitation is that SASL is(/can be) stateful, and the state is currently kept in a worker process. If different worker processes handle the different steps of the same authentication flow then the state will be a problem, as it is currently not shared between worker processes. Sadly the state used by cyrus sasl contains all kind of pointers, especially function pointers (which should be the same, but this is depending also on the SASL mech probably) and thus using shared memory to share the contexts could lead to problems.

Even more of a limitation is if the SASL auth is terminated at servers behind a load balancer, the SASL state must be known by the backend server, otherwise it will not succeed, thus a load balancer must make sure that the same backend server is used for the whole of a SASL auth execution.

** Variables

This module setst the following nginx variables:

*** sasl_secure Is only "yes" (without the quotes) when a client is authenticated to the current resource. It never has another value; it is simply undefined when not secured by SASL

*** sasl_realm Is the realm for which the secure exchange succeeded. A realm is not always used, because sites only need it when there are more than one in the same name space. When undefined in the SASL flow, this variable will not be set.

*** sasl_user Is the client identity as confirmed through SASL authentication. Its content is formatted like an email address, and includes a domain name. That domain need not be related to the web server; it is possible for a web server to welcome foreign clients.

*** sasl_mech Indicates the mechanism used, and is one of the standardised SASL mechanism names. It may be used to detect the level of security.

** Config

A minimal example config with verbose logging:

+BEGIN_EXAMPLE

error_log logs/error.log debug; events { } http { auth_sasl localhost; sasl_realm localhost; sasl_mechanisms "OPAQUE"; sasl_db_path /usr/local/etc/sasldb2;

add_header X-SASL-SECURE $sasl_secure; add_header X-REMOTE-USER $sasl_user; add_header X-SASL-REALM $sasl_realm; add_header X-SASL-MECH $sasl_mech;

server { listen *:8090; root .; } }

+END_EXAMPLE

** Credits

This project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310.