Topic: authentication/authorization failure upgrade 2.2->2.4

[gursoz]

Cannot pass authentication/authorization, when I comment out "Satisfy any" in configuration file in Apache 2.4. Have ported all other configuration directive successfully from 2.2 to 2.4. Only this one remains.

Apache version: 2.4
operating system SLES-12 (suse release 12)

conf file change
Success case ("Satisfy any" is not commented out)
<Location /misc>
PerlFixupHandler MOD_SEC_XXX::AccessHandler
ProxyPass !
Require all denied
AuthType CAS
AuthName "XXX XXX"
CASScope /
Require valid-user
Satisfy any
ErrorDocument 403 /service/403.html
</Location>

Error case ("Satisfy any" is commented out)
<Location /misc>
PerlFixupHandler MOD_SEC_XXX::AccessHandler
ProxyPass !
Require all denied
AuthType CAS
AuthName "XXX XXX"
CASScope /
Require valid-user
#Satisfy any
ErrorDocument 403 /service/403.html
</Location>


indications in the log files -
error.log

In the error log, I first start getting differences in the following lines. Notice that the failure case has extra "referer: https://10.108.53.24/index.html" appended.

With Saitisfy Any (i.e. successful case)
=========================================
[Thu Aug 13 19:51:19.542796 2015] [ssl:debug] [pid 2652:tid 140563659609856] ssl_engine_kernel.c(243): [client 10.96.32.15:61816] AH02034: Subsequent (No.3) HTTPS request received for child 1 (server localhost:443)
[Thu Aug 13 19:51:19.560537 2015] [ssl:info] [pid 2653:tid 140563659609856] [client 10.96.32.15:61819] AH01964: Connection to child 65 established (server localhost:443)
[Thu Aug 13 19:51:19.597840 2015] [ssl:debug] [pid 2653:tid 140563659609856] ssl_engine_kernel.c(1936): [client 10.96.32.15:61819] AH02645: Server name not provided via TLS extension (using default/first virtual host)
[Thu Aug 13 19:51:19.598552 2015] [authz_core:debug] [pid 2652:tid 140563659609856] mod_authz_core.c(802): [client 10.96.32.15:61816] AH01626: authorization result of Require all granted: granted
[Thu Aug 13 19:51:19.619497 2015] [authz_core:debug] [pid 2652:tid 140563659609856] mod_authz_core.c(802): [client 10.96.32.15:61816] AH01626: authorization result of <RequireAny>: granted


without Satisfy Any (i.e. failure case)
=========================================
[Thu Aug 13 20:01:54.404524 2015] [ssl:debug] [pid 24290:tid 139774081885952] ssl_engine_kernel.c(243): [client 10.96.32.15:51431] AH02034: Subsequent (No.3) HTTPS request received for child 0 (server localhost:443), referer: https://10.108.53.24/index.html
[Thu Aug 13 20:01:54.570691 2015] [authz_core:debug] [pid 24290:tid 139774081885952] mod_authz_core.c(802): [client 10.96.32.15:51431] AH01626: authorization result of Require all granted: granted, referer: https://10.108.53.24/index.html
[Thu Aug 13 20:01:54.575166 2015] [ssl:info] [pid 24291:tid 139773997958912] [client 10.96.32.15:51432] AH01964: Connection to child 74 established (server localhost:443)
[Thu Aug 13 20:01:54.599640 2015] [authz_core:debug] [pid 24290:tid 139774081885952] mod_authz_core.c(802): [client 10.96.32.15:51431] AH01626: authorization result of <RequireAny>: granted, referer: https://10.108.53.24/index.html
[Thu Aug 13 20:01:54.600138 2015] [ssl:debug] [pid 24291:tid 139773997958912] ssl_engine_kernel.c(1936): [client 10.96.32.15:51432] AH02645: Server name not provided via TLS extension (using default/first virtual host)
[Thu Aug 13 20:01:54.751072 2015] [ssl:debug] [pid 24291:tid 139773997958912] ssl_engine_kernel.c(1841): [client 10.96.32.15:51432] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

access.log

Thanks,

Amit.

[glsmith]

It's probably best you throw out everything you know about 2.2's order,allow,deny,satisfy and bite into 2.4's new way of authentication and authorization. You can also unload mod_access_compat as well once you get a grasp of it.

With 2.4 you use Require and there is an implied <RequireAny>.

So if you had

Require ip 123.123.123.123
Require valid-use

A person coming from the ip 123.123.123.123 would not have to log in but be granted access. Every other IP would have to log in.

So in your case, "Require all denied" shoots you in the foot because of the "all" so you must use the Satisfy any and I am still surprised it works. 2.4 even with mod_access_compat didn't like mix-and-match 2.2/2.4 styles but maybe that's been fixed.

Your 3 lines of

Require all denied
Require valid-user
Satisfy any

Can now be done with just one

Require valid-user

Only valid users will be allowed access.

I'd suggest reading the docs for Require, <RequireAll>, <RequireAny>, <RequireNone> and reviewing the Authentication and Authoriztion. In this last one you may notice the last sentence of the "Applying logic and ordering" section talks about the implied RequireAny.

[gursoz]

Thanks a lot for your reply.

Cleaned up according to your suggestion, removed “mod_access_compat.so”. Still the issue happened until I put in a home grown perl-script in each block where we use “Require valid-user”.

For example, in the block below, if I comment out the line “PerlAccessHandler Apache::FreeAccess”, I get access denied error. This line was not needed in 2.2.

Initially I thought that may be inclusion of the line bypass "Require valid-user", because the default behavior is Require Any. But that's not the case. Still, the line "Require valid-user" is being executed because in the login page if I input wrong username/password, access is denied.

<Location /all-classes.js>
PerlAccessHandler Apache::FreeAccess
PerlFixupHandler MOD_SEC_EMC::AccessHandler
ProxyPass !
AuthType CAS
AuthName "XXXXX"
CASScope /
Require valid-user
ErrorDocument 403 /service/403.html
</Location>


The free access script is below, essentially it's just returning OK.
+++++++++++
package Apache::FreeAccess;

use strict;
use Apache2::Const qw(:common); # MAE 10/20/08 - RHEL5 Upgrade : Rename Apache to Apache2

sub handler {
return OK;
}
1;
__END__
+++++++++++

In 2.2, I never had to include the PerlAccessHandler in each block where I use "Require valid-user".

Can you explain why inclusion of the above resolves the issue?

Thanks,

Amit.

[glsmith]

Sorry about the very late reply but I cannot answer this. You are using 3rd party authentication method that I am unfamiliar with. Access and authentication had serious major changes between 2.2 and 2.4 and this may just be a symptom of that. It's the modules job to deal with it. If configuration change is neccessary, so be it.