[wildfly-dev] 13 JASPIC tests failing on WildFly
Arun Gupta
arun.gupta at gmail.com
Wed Dec 11 20:50:34 EST 2013
Stefan,
Thanks, waiting for the PR!
Are these JBoss-specific deployment descriptors required because the
spec is under specified ?
Arun
On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen <sguilhen at redhat.com> wrote:
> 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>
>> 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
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
http://blog.arungupta.me
http://twitter.com/arungupta
More information about the wildfly-dev
mailing list