[wildfly-dev] 13 JASPIC tests failing on WildFly
Stefan Guilhen
sguilhen at redhat.com
Wed Dec 11 21:20:57 EST 2013
Hi Arun,
As there is no standard for the configuration of JASPI modules we have
historically used the security domain for that. The descriptor is needed
to link the web application to the security domain that contains the
JASPI configuration and the container uses the security domain config to
determine if JAAS or JASPI will be used to authenticate users.
Also note that in WF (and all previous JBoss AS versions) JASPI is not
enabled by default as the specs don't require us to do that, so we rely
on this security domain config to enable it. I've had a discussion with
Pedro - dev who implemented the JASPI mechanism for WildFly - a couple
of months ago and we thought the configuration needed to be revisited
but we have never had the time to do that.
Cheers,
Stefan
On 12/11/2013 11:50 PM, Arun Gupta wrote:
> 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
>
>
More information about the wildfly-dev
mailing list