Bug 1262482 - [GSS] (6.4.z) Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
[GSS] (6.4.z) Unhandled exceptions from custom JASPI modules should cause the...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security (Show other bugs)
6.4.3
Unspecified Unspecified
high Severity unspecified
: CR1
: EAP 6.4.8
Assigned To: Bartek Spyrko-Smietanko
Josef Cacek
:
Depends On:
Blocks: eap648-payload
  Show dependency treegraph
 
Reported: 2015-09-11 16:47 EDT by Derek Horton
Modified: 2017-01-17 07:35 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-17 07:35:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-5416 Major Resolved Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc) 2017-03-21 07:40 EDT

  None (edit)
Description Derek Horton 2015-09-11 16:47:05 EDT
Description of problem:

If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200. The web page that was requested does not get displayed. A blank page and a HTTP 200 are returned.
Should a 40x or a 500 be returned instead? Or is it the responsibility of the custom JASPI auth module to set the status correctly?
It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set.

Steps to Reproduce:
1.  Build a custom JASPI module that throws an exception
2.  Configure a security domain to use JASPI

    <security-domain name="jmx-console" cache-type="default">
        <authentication-jaspi>
            <login-module-stack name="lm-stack">
                <login-module code="UsersRoles" flag="required">
                    <module-option name="usersProperties" value="file:///${jboss.server.config.dir}/users.properties"/>
                    <module-option name="rolesProperties" value="file:///${jboss.server.config.dir}/roles.properties"/>
                </login-module>
            </login-module-stack>
            <auth-module code="org.jboss.example.CustomJaspiAuthModule" flag="required" login-module-stack-ref="lm-stack" module="org.jboss.example"/>
        </authentication-jaspi>
    </security-domain>

3.  Configure the application to use the JASPI valve

<jboss-web>  
   <security-domain>jaspi-test</security-domain>  
   <valve>  
      <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name>  
   </valve>  
</jboss-web>

4.  Hit the web application and look at the HTTP status that is returned
Comment 11 Mike McCune 2016-03-28 18:21:53 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 13 Jiří Bílek 2016-05-17 04:55:58 EDT
Verified with EAP 6.4.8.CP.CR2
Comment 14 Petr Penicka 2017-01-17 07:35:07 EST
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Note You need to log in before you can comment on or make changes to this bug.