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)
Summary: [GSS] (6.4.z) Unhandled exceptions from custom JASPI modules should cause the...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security
Version: 6.4.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: CR1
: EAP 6.4.8
Assignee: Bartek Spyrko-Smietanko
QA Contact: Josef Cacek
URL:
Whiteboard:
Depends On:
Blocks: eap648-payload
TreeView+ depends on / blocked
 
Reported: 2015-09-11 20:47 UTC by Derek Horton
Modified: 2019-10-10 10:11 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 12:35:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-5416 0 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 11:40:50 UTC

Description Derek Horton 2015-09-11 20:47:05 UTC
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 22:21:53 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 13 Jiří Bílek 2016-05-17 08:55:58 UTC
Verified with EAP 6.4.8.CP.CR2

Comment 14 Petr Penicka 2017-01-17 12:35:07 UTC
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.