Hi.
Version info :
[Sun Sep 13 06:25:05.107620 2020] [mpm_prefork:notice] [pid 4125] AH00163: Apache/2.4.25
(Debian) OpenSSL/1.0.2u mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 Perl/v5.24.1 configured
-- resuming normal operations
Background :
We have developed our own AAA "authorization" scheme, based on mod_perl.
This scheme is such that for the authentication part, it can use any available "standard"
Apache module/scheme (such as ldap (mod_authnz_ldap), Shibboleth (mod_shib2), Basic auth
(mod_auth_core), etc.. (including some which we developed ourselves)), and the
Authorization phase will "delegate" the authentication to whatever authentication method
is configured, and subsequently "collect" the authentication information in order to
authorize or not access, and provide the subsequent applications with a user profile in a
standard format.
(Thus, in this case, we intend to use mod_authnz_ldap as the authentication method, but
use our own module as the authorization code.)
Our issue :
When mod_authnz_ldap is used to authenticate the user (via the HTTP Basic browser dialog),
the following happens :
a) if the user-entered userid / pw are correct, everything happens as expected (our
authorization module gets called subsequently, and the user ultimately gets access to the
desired resource)
b) if the user-entered userid is valid, but the entered password is not, the server
(presumably mod_authnz_ldap) returns a 401 response. (This happens without our
authorization module being called).
As a consequence, the user gets a new HTTP Basic login dialog, in which he can re-enter a
valid combination; and if he does, everything happens as expected, as per the first case
above.
c) but if the user-entered *userid* is invalid (iow it does not exist in the LDAP
directory), then the server returns a server error 500 status immediately, without calling
our authorization module. Subsequent page reloads in the browser always return the same
server error 500.
(c) is a problem, because from the user perspective, it is really unclear why the
authentication failed, and in addition, the only way in which they can retry is by closing
the browser, re-opening it, and retry to access the same URL (this is because apparently,
although the authentication failed, the browser nevertheless caches the wrong Basic
credentials, and re-submits the same at any subsequent attempt to reload the same resource).
It is also a problem for us, because there sems to be no way in which we can "intervene"
in case (c) : our authorization method is not even called; upon return from the
mod_authnz_ldap authenticate function, httpd just goes straight to sending back a server
error page (and with a strange error in the log, see below).
In the Apache error log, this is what case (c) looks like :
(UMA2 is our self-developed "authorization provider", and I have numbered the log lines
for further reference).
1) [Fri Sep 18 10:50:42.349048 2020] [perl:info] [pid 12610] [client 10.142.225.37:37964]
<--UMA2[12610]authz_user.PASS1: (no user, will now call configured authentication method(s))
2) [Fri Sep 18 10:50:42.349085 2020] [authz_core:debug] [pid 12610] mod_authz_core.c(809):
[client 10.142.225.37:37964] AH01626: authorization result of Require UMA-user valid-user:
denied (no authenticated user yet)
3) [Fri Sep 18 10:50:42.349098 2020] [authz_core:debug] [pid 12610] mod_authz_core.c(809):
[client 10.142.225.37:37964] AH01626: authorization result of <RequireAny>: denied (no
authenticated user yet)
4) [Fri Sep 18 10:50:42.349142 2020] [authnz_ldap:debug] [pid 12610]
mod_authnz_ldap.c(520): [client 10.142.225.37:37964] AH01691: auth_ldap authenticate:
using URL ldap://(redacted, but works fine in other cases)
[Fri Sep 18 10:50:42.349163 2020] [authnz_ldap:trace1] [pid 12610] mod_authnz_ldap.c(541):
[client 10.142.225.37:37964] auth_ldap authenticate: final authn filter is
(&(ltbbFreeAttribute11=1)(uid=parltest3))
5) [Fri Sep 18 10:50:42.367039 2020] [authnz_ldap:info] [pid 12610] [client
10.142.225.37:37964] AH01695: auth_ldap authenticate: user (redacted) authentication
failed; URI /auth-test/ELVISb/test-auth.html [User not found][No such object]
6) [Fri Sep 18 10:50:42.367075 2020] [authn_core:error] [pid 12610] [client
10.142.225.37:37964] AH01796: AuthType basic configured without corresponding module
(the last line is where httpd returns the server error 500 page to the browser)
At (1), our authorization method (which is called first because of a "Require") returns
AUTHZ_DENIED_NO_USER to httpd. This triggers the call to the configured authentication
method. Lines (2)-(6) do not involve our authorization code at all anymore.
It seems that the last error log message (6) is somewhat nonsensical, because :
1) the (somewhat edited/simplified) configuration is as follows :
...
PerlAddAuthzProvider UMA-user AUTH::UMA2->authz_user
...
<LocationMatch "/ELVISb/.*$">
# for AAA : LDAP login
AuthName LBBLDAP
AuthType basic
AuthBasicProvider ldap
AuthBasicAuthoritative Off
AuthLDAPURL
ldap://(redacted):7389/o=(redacted),c=de?uid,email,displayName?sub?(ltbbFreeAttribute11=1) TLS
AuthLDAPBindDN
"cn=(redacted),cn=memberserver,cn=computers,o=(redacted),c=de"
AuthLDAPBindPassword "(redacted)"
AuthLDAPBindAuthoritative off
# and here either :
<RequireAll>
# Require valid-user triggers the LDAP/Basic auth
Require valid-user
# Require UMA-user valid-user triggers the UMA2->authz_user
sub.,
# then also Basic/LDAP authentication (if no cookie yet)
Require UMA-user valid-user
</RequireAll>
# or simply :
Require UMA-user valid-user
#(same behaviour on both cases)
</LocationMatch>
(so the "corresponding module" is configured as "ldap")
and 2) httpd already called this ldap provider during the first pass, since it is the one
which returned the 401 response triggering the browser's authentication dialog
Note also that this configuration works perfectly in the above-mentioned cases
(a) and (b).
Digging a bit further yelded these links which may be of interest :
-
https://github.com/omnigroup/Apache/blob/master/httpd/modules/aaa/mod_authn_core.c#L343-L359
-
https://github.com/omnigroup/Apache/blob/master/httpd/include/mod_auth.h#L64-L70
-
https://github.com/omnigroup/Apache/blob/master/httpd/modules/aaa/mod_authnz_ldap.c#L548-L560
But I am unable to say if the behaviour we are seeing is expected, or if we are making a
mistake in our configuration.
Can anyone help ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
