[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