[wildfly-dev] 13 JASPIC tests failing on WildFly

Stefan Guilhen sguilhen at redhat.com
Wed Dec 11 20:26:24 EST 2013


Indeed, I've taken a look at your tests and the solution is pretty clean 
although I have to agree with Anil that having a standard for the config 
would help a lot.

As a side note, the results are not as bad as they seem. The 
javaee7-samples project is missing a few jboss-web.xml descriptors and 
there's also an issue with HttpUnit throwing an exception that prevents 
certain tests from completing. I'm taking a look into these issues and 
will send a PR for the javaee7-samples project with a few fixes. I 
believe we will see much better numbers after that.

Stefan

On 12/11/2013 06:51 PM, arjan tijms wrote:
> Hi,
>
>     I had stressed for standardization of the JASPI configuration. The
>     spec lead wanted to keep it open. This was early days of the JSR.
>     I seriously doubt you can have auth modules written once and
>     deploy on any app server. 
>
> Actually it doesn't seem to be that bad. Using the programmatic 
> registration method (which is the only standardized method) pretty 
> much every app server installs the SAM just fine (Geronimo is the sole 
> exception).
>
> Yes, the first time it's a hassle that you have to code the wrapper 
> AuthConfigProvider, ServerAuthConfig etc types, but once you hide that 
> away inside a utility method it's a one liner to install a SAM from a 
> ServletContextListener. This is exactly what the tests that I 
> committed do:
>
> @WebListener public class SamAutoRegistrationListener extends 
> BaseServletContextListener { @Override public void 
> contextInitialized(ServletContextEvent sce) { 
> JaspicUtils.registerSAM(sce.getServletContext(), new 
> TestServerAuthModule()); } }
> It's perhaps a shame there's no declarative alternative, but this 
> method itself is IMHO not wrong per se. The Servlet spec defines 
> similar APIs for registering Servlets and Filters programmatically.
>
> After working with JASPIC rather intensively for well over a year now 
> I can say that it does work in a portable way. The main issue is the 
> multitude of bugs in the various implementations and/or 
> implementations just not doing what's in the spec.
>
> For instance, secureResponse should be called AFTER the resource (e.g. 
> a Servlet or JSP page) is invoked, but some implementations 
> erroneously call it before the resource is invoked. This makes it 
> impossible to use this method for a SAM that has to be portable. The 
> spec is clear on this topic, but the app servers just don't always do 
> the right thing.
>
> Some aspects of the spec are just ignored by pretty much all servers, 
> like the ability of a SAM to wrap the request and response objects 
> (just like a Servlet Filter can do). For the open source servers it 
> can be seen that this functionality is not even attempted. Ironically, 
> GlassFish does attempt it, but due to a rather complicated bug it 
> eventually fails to deliver the wrapped request to the resource, while 
> it does deliver the wrapped response correctly.
>
> So IMHO 90% of the non-portability of a SAM is just due to 
> implementation bugs. Many of them are rather trivial to fix. Hopefully 
> having a series of tests can help remedy this issue ;)
>
> Kind regards,
> Arjan Tijms
>
>     That was the goal of the spec but I don't think it really has
>     reached that potential. As Stefan said, let us wait for all the
>     JASPI related PRs to be merged before looking into the failures.
>
>
> On 12/11/2013 08:12 AM, Arun Gupta wrote:
> >/  I changed the <security-domain> to:
> />/
> />/  <security-domain name="jaspitest" cache-type="default">
> />/                       <authentication-jaspi>
> />/                           <login-module-stack name="dummy">
> />/                               <login-module code="Dummy" flag="optional"/>
> />/                           </login-module-stack>
> />/                           <auth-module
> />/  code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> />/  flag="required"/>
> />/                       </authentication-jaspi>
> />/                   </security-domain>
> />/
> />/  and getting more failures. Will wait for the PR to be merged.
> />/
> />/  Arun
> />/
> />/  On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com  <https://lists.jboss.org/mailman/listinfo/wildfly-dev>> wrote:
> />>/  Actually they seem to be registering their own AuthConfigProvider, in
> />>/  which case the dummy domain setup is fine (configuring our auth-module
> />>/  impl won't do anything as their provider will register their own test
> />>/  module), so disregard my previous e-mail.
> />>/
> />>/  Note that there is a pending pull request
> />>/  (https://github.com/wildfly/wildfly/pull/5558/) that seems to fix a few
> />>/  of the issues seen in the tests. Lets run the tests again once the PR is
> />>/  merged to and see where we stand.
> />>/
> />>/  Stefan
> />>/
> />>/  On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
> />>>/  If you are using the security domain as mentioned in the commit any
> />>>/  authentication will fail because there is no "dummy" auth-module. I
> />>>/  couldn't find the WildFly log but there must be exceptions there
> />>>/  indicating it was not possible to load the auth-module class.
> />>>/
> />>>/  Try setting the auth module in the security domain to
> />>>/
> />>>/  <auth-module
> />>>/  code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
> />>>/  flag="required"/>
> />>>/
> />>>/  And see how it goes.
> />>>/
> />>>/  Stefan
> />>>/
> />>>/  On 12/10/2013 10:16 PM, Arun Gupta wrote:
> />>>>/  Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
> />>>>/
> />>>>/  https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
> />>>>/
> />>>>/  13 of them are failing with WildFly as shown at:
> />>>>/
> />>>>/  https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/
> />>>>/
> />>>>/  21 of these tests are passing on GlassFish as shown at:
> />>>>/
> />>>>/  https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/
> />>>>/
> />>>>/  JASPIC support in WildFly is reported "broken" as mentioned at:
> />>>>/
> />>>>/  https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724
> />>>>/
> />>>>/  Adding a new <security-domain> as mentioned in the above commit
> />>>>/  message only marginally improves the results.
> />>>>/
> />>>>/  Do you see any basic configuration issue with OOTB WildFly for running
> />>>>/  these tests ?
> />>>>/
> />>>>/  Arun
> />>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131211/037bc949/attachment-0001.html 


More information about the wildfly-dev mailing list