@@ -7,9 +7,12 @@ A helper that allows Nginx to lookup from Active Directory / LDAP
7
7
if a user is authorized to access some resource, _ after_ said user
8
8
has been authenticated by some other means (Kerberos, Basic auth, Token, ...).
9
9
10
+ Optionally, it can also return user attributes (such as name, email, etc) to Nginx
11
+ in HTTP headers.
12
+
10
13
Technically it's a small HTTP server that reads usernames from request headers
11
14
and performs configured LDAP queries with them, returning status 200 if query
12
- succeeded or 403 if it failed; an HTTP- >LDAP proxy of sorts.
15
+ succeeded or 403 if it failed; an HTTP< >LDAP proxy of sorts.
13
16
Nginx can auth against such a thing with the ´auth_request`
14
17
directive. Results are cached for a configurable amount of time.
15
18
@@ -19,15 +22,15 @@ The server is configured with an INI file, such as:
19
22
20
23
``` ini
21
24
[default]
22
- ldap_server_url = ldap://dc1.example.test
25
+ ldap_server_url = ldap://dc1.example.test:389
23
26
ldap_conn_timeout = 10.0
24
27
ldap_bind_dn = CN =service,CN =Users,DC =example,DC =test
25
28
ldap_bind_password = password123
26
29
ldap_search_base = DC =example,DC =test
27
30
28
- ldap_cache_size = 1024
31
+ ldap_return_attribs = displayName, givenName, sn, mail
29
32
ldap_cache_time = 30
30
-
33
+ ldap_cache_size = 512
31
34
username_http_header = X-Ldap-Authz-Username
32
35
33
36
[users]
@@ -46,6 +49,27 @@ that is tested against HTTP requests. If it matches, `ldap_query` from that sect
46
49
is executed after replacing ` %USERNAME% ` with the username from ` username_http_header ` HTTP header.
47
50
If the LDAP query succeeds, server returns status 200, otherwise 403.
48
51
52
+ The ` ldap_return_attribs ` , if not empty, specifies a comma-separated list of LDAP
53
+ attributes to return to Nginx in HTTP headers. The header names are prefixed with
54
+ ` X-Ldap-Authz-Res- ` , so for example ` displayName ` attribute is returned in
55
+ ` X-Ldap-Authz-Res-displayName ` header. Use ` ldap_return_attribs = * ` to return all
56
+ attributes (mainly useful for debugging).
57
+
58
+ If LDAP query returns multiple results, the first one is used. To see all results,
59
+ use ` --debug ` option to write them to log.
60
+
61
+ ## Cache
62
+
63
+ The server uses a simple in-memory cache to avoid performing the same LDAP queries
64
+ over and over again. Cache size is limited to ` ldap_cache_size ` entries, and
65
+ entries are removed in LRU order. Cache time is ` ldap_cache_time ` seconds.
66
+ One cache entry is created for each unique username, so ldap_cache_size should
67
+ be large enough to accommodate all users that might be accessing the server simultaneously.
68
+ A cache entry takes probably about 1kB of RAM, unless you requested all LDAP attributes.
69
+
70
+ Technically, each config section gets its own cache, so you can have different cache sizes and
71
+ retention times for different sections.
72
+
49
73
## Building
50
74
51
75
The server is written in Rust and can be built with ` cargo build --release ` .
@@ -107,10 +131,11 @@ This is the recommended way to install it when applicable.
107
131
108
132
Use ` ./run-tests.sh ` to execute test suite. It requires ` docker compose `
109
133
and ` curl ` . The script performs an end-to-end integratiot test with a
110
- real LDAP server (Active Directory in this case, using Samba) and an
111
- Nginx reverse proxy. It spins up necessary containers, and then performs
112
- Curl HTTP requests against Nginx, comparing their HTTP response status codes to
113
- expected values.
134
+ real Active Directory server and an Nginx reverse proxy.
135
+
136
+ It spins up necessary containers, sets up example users, and then performs
137
+ Curl HTTP requests against Nginx, comparing their HTTP response status codes
138
+ and headers to expected values.
114
139
115
140
## Nginx configuration
116
141
@@ -120,8 +145,8 @@ with the Basic method and then authorized with this server using _auth_request_
120
145
### Kerberos
121
146
122
147
This software was originally developed for Active Directory auth using
123
- Nginx, so here's a complementary real-world example on how to authenticate users against AD with
124
- Kerberos (spnego-http-auth-nginx-module) and to then authorize them using
148
+ Nginx, so here's a complementary example on how to authenticate some API users
149
+ against AD with Kerberos (spnego-http-auth-nginx-module) and to then authorize them using
125
150
_ ldap_authz_proxy_ :
126
151
127
152
``` nginx
@@ -140,7 +165,8 @@ server {
140
165
auth_gss_force_realm on;
141
166
auth_gss_service_name HTTP/www.example.com;
142
167
143
- auth_request /authz_all;
168
+ auth_request /authz_all;
169
+ auth_request_set $display_name $upstream_http_x_ldap_res_displayname;
144
170
145
171
location = /authz_all {
146
172
internal;
@@ -150,10 +176,15 @@ server {
150
176
proxy_set_header X-Ldap-Authz-Username $remote_user;
151
177
}
152
178
153
- location / {
154
- root /var/www/;
155
- index index.html;
156
- try_files $uri $uri/ =404;
179
+ location /api {
180
+ proxy_pass http://127.0.0.1:8095/api;
181
+
182
+ # Pass authenticated username to backend
183
+ proxy_set_header X-Remote-User-Id $remote_user;
184
+ proxy_set_header X-Remote-User-Name $display_name;
185
+
186
+ proxy_set_header X-Real-IP $remote_addr;
187
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
157
188
}
158
189
}
159
190
```
0 commit comments