Bug 920160

Summary: Unauthorized access to a web application protected with a custom authorization module results in HTTP 200 (OK) instead of HTTP 403 (Forbidden)
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Josef Cacek <jcacek>
Component: SecurityAssignee: Emmanuel Hugonnet (ehsavoie) <ehugonne>
Status: CLOSED CURRENTRELEASE QA Contact: Josef Cacek <jcacek>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1.0CC: asaldhan, ehugonne, jlivings, olukas, pskopek, rdickens
Target Milestone: ER3   
Target Release: EAP 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In JBoss EAP 6.1.0, unauthorized access to a web application protected with a custom authorization module resulted in an HTTP response of 200 (OK) instead of HTTP 403 (Forbidden). This issue has been resolved and the correct response is now provided.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-15 16:18:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
secured-webapp-deny.war reproducer with custom (AllDeny) authorization module none

Description Josef Cacek 2013-03-11 13:28:13 UTC 
Created attachment 708374 [details]
secured-webapp-deny.war reproducer with custom (AllDeny) authorization module

If a web application is protected by a custom authorization module, then the user doesn't recognize, he is not allowed to access the requested page, because he gets HTTP 200 (OK) response.

How to reproduce:

1) Save attached secured-webapp-deny.war application to $JBOSS_HOME/standalone/deploy folder

2) Define new security domain with custom authorization module in standalone.xml:

<security-domain name="test-deny">
    <authentication>
        <login-module code="UsersRoles" flag="required"/>
    </authentication>
    <authorization>
        <policy-module code="org.jboss.security.authorization.modules.AllDenyAuthorizationModule" flag="required"/>
    </authorization>
</security-domain>

3) Make HTTP request (with admin/admin credentials):

$ curl -v http://admin:admin@localhost:8080/secured-webapp-deny/
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
* Server auth using Basic with user 'admin'
> GET /secured-webapp-deny/ HTTP/1.1
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Pragma: No-cache
< Cache-Control: no-cache
< Expires: Thu, 01 Jan 1970 01:00:00 CET
< Content-Length: 0
< Date: Mon, 11 Mar 2013 13:14:07 GMT
< 
* Connection #0 to host localhost left intact
* Closing connection #0

Empty response with HTTP/1.1 200 OK is returned.
IMO status code 403 should be returned in this case.
Comment 1 Josef Cacek 2013-03-11 13:30:55 UTC 
Stacktrace printed when DEBUG level is enabled:

14:14:07,550 DEBUG [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000299: Required module org.jboss.security.authorization.modules.AllDenyAuthorizationModule failed
14:14:07,556 DEBUG [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000326: hasUserDataPermission processing failed: org.jboss.security.authorization.AuthorizationException: PBOX000017: Acces denied: authorization failed 
	at org.jboss.security.plugins.authorization.JBossAuthorizationContext.invokeAuthorize(JBossAuthorizationContext.java:268) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.security.plugins.authorization.JBossAuthorizationContext.access$000(JBossAuthorizationContext.java:71) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.security.plugins.authorization.JBossAuthorizationContext$1.run(JBossAuthorizationContext.java:147) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_11]
	at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:143) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:429) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:268) [picketbox-4.0.15.Final-redhat-1.jar:4.0.15.Final-redhat-1]
	at org.jboss.as.web.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:625) [jboss-as-web-7.2.0.Final-redhat-2.jar:7.2.0.Final-redhat-2]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:417) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-2.jar:7.2.0.Final-redhat-2]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_11]
Comment 3 Emmanuel Hugonnet (ehsavoie) 2013-07-22 08:04:52 UTC 
[vendredi 19 juillet 2013] [17:46:33] <ehsavoie> how/where does undertow delegates the access authorization ? I see the authentication part but not the authorization
[vendredi 19 juillet 2013] [17:48:24] <darranl> ehsavoie, no Undertow authorization is based on roles defined in the deployment so it performs that check itself 
[vendredi 19 juillet 2013] [17:49:27] <ehsavoie> darranl: so how does it access the authorization plugin for the security domain ?
[vendredi 19 juillet 2013] [17:50:01] <ehsavoie> darranl: somewhere it has to delegate
[vendredi 19 juillet 2013] [17:51:06] <darranl> ehsavoie, not sure if that mapping is currently in, longer term the plan is to move away from the JAAS domains 
[vendredi 19 juillet 2013] [17:52:03] <ehsavoie> darranl: that means that https://bugzilla.redhat.com/show_bug.cgi?id=920160 is not relevant in wildfly ?
[vendredi 19 juillet 2013] [17:52:08] <jbossbot> bugzilla [3JBoss Enterprise Application Platform 6 #920160] Unauthorized access to a web application protected with a custom authorization module results in HTTP 200 (OK) instead of HTTP 403 (Forbidden) [10NEW Bug,7 high,6 Anil Saldhana] https://bugzilla.redhat.com/show_bug.cgi?id=920160
[vendredi 19 juillet 2013] [17:52:42] <darranl> ehsavoie, correct
Comment 4 Emmanuel Hugonnet (ehsavoie) 2013-07-22 13:58:35 UTC 
https://github.com/ehsavoie/jboss-eap/tree/BZ-920160 is ready to fix this issue.
Comment 5 Emmanuel Hugonnet (ehsavoie) 2013-09-09 15:04:28 UTC 
https://github.com/jbossas/jboss-eap/pull/362
Comment 6 Ondrej Lukas 2013-09-25 10:08:10 UTC 
Verified on 6.2.0.ER3
Comment 10 Russell Dickenson 2013-11-21 03:51:45 UTC 
Release notes text written, to be published at EAP 6.2.0's GA.