https://github.com/stef/ngx_http_auth_sasl_module
SASL authentication module for nginx
https://github.com/stef/ngx_http_auth_sasl_module
Last synced: about 1 year ago
JSON representation
SASL authentication module for nginx
- Host: GitHub
- URL: https://github.com/stef/ngx_http_auth_sasl_module
- Owner: stef
- License: other
- Created: 2022-05-21T21:12:18.000Z (about 4 years ago)
- Default Branch: master
- Last Pushed: 2022-07-28T19:17:59.000Z (almost 4 years ago)
- Last Synced: 2025-04-16T00:11:24.139Z (about 1 year ago)
- Language: C
- Size: 52.7 KB
- Stars: 3
- Watchers: 4
- Forks: 2
- Open Issues: 1
-
Metadata Files:
- Readme: README.org
- License: LICENSE
Awesome Lists containing this project
README
* NGINX HTTP SASL authentication module
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.