13 JASPIC tests failing on WildFly

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

13 JASPIC tests failing on WildFly

arjan.tijms
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Stefan Guilhen
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Arun Gupta
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
http://blog.arungupta.me
http://twitter.com/arungupta
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Stefan Guilhen
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
Hi Stefan,

On Thursday, December 12, 2013, Stefan Guilhen wrote:
Hi Arun,

As there is no standard for the configuration of JASPI modules we have
historically used the security domain for that.

Indeed, if one wants to configure a SAM (or possibly other JASPIC module) for the entire application server outside of any deployed application in a declarative way, then a concept like the JBoss security domain is appropriate.

However, when the application registers its own local SAM (with wrappers) then such a security domain is not needed. None of the other application servers require something like it. The logic seems to be:

1. Check if there is a local SAM (matching app context id)
2. Check if there is a global SAM (using null as app context id)
3. Check if there is any proprietary mechanism in place (typically called realm, domain, zone, etc).

Because of 2. you can also more or less portably register/configure a SAM for the entire server by deploying a single .war with just a SAM and the aforementioned context listener and then just passing in null for the app context id. The spec defines that all contexts (all apps) on that server should then use that module.
 
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,

Would you happen to know which section of the spec exactly states this? I've read the spec a couple of times over, but couldn't really find anything. As the spec prose in case of the JASPIC spec is a bit difficult to digest I might have missed it.

I do know that in every other server there is no need at all to explicitly enable JASPIC. Just the mere act of using the standard factory to register the (wrapped) SAM is enough for those other servers.

 
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.

It would be absolutely great if WildFly could make the security domain thing optional for JASPIC. 

I interviewed a couple of developers about Java EE security and by far the biggest pain point seems to be with the (to them) awkward vendor specific xml files that are needed to get security going. (Note that while the other servers don't have the required valve like in JBoss EAP 6 or the security domain, they do have required vendor specific group to role mapping files which are just as painful).

The concept of a security domain also causes another issue in JBoss. The EJB spec does mention something about this for secured EJB beans (with a security interceptor via @RolesAllowed) but reasonably I think the spec intends this section to apply only for remote connections to a bean. 

But JBoss always consults this security domain, even for local calls and when the caller has already been authenticated (via JASPIC or otherwise). 

The problem is that the EJB security interceptor only knows how to deal with a JAAS login module, it doesn't know how to deal with JASPIC. Since JASPIC has no profile for an EJB "message exchange" this wouldn't work in a portable way no matter what.

All other servers seem to just propagate the existing authenticated identity and thus the case of a JASPIC login in the web layer followed by a call to an EJB with an @RolesAllowed works. In JBoss this always fails.

Also note that only the security interceptor tries to re-authenticate. The implementation of the isCallerInRole method on the EJBContext does not attempt this in JBoss and can thus theoretically work (but it too doesn't work in JBoss EAP 6.x due to a bug, which is again rather trivial to fix).

Kind regards,
Arjan Tijms


 

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 <[hidden email]> 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:

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Stefan Guilhen
Hi Arjan,

These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.

Cheers,
Stefan

On 12/12/2013 09:31 AM, arjan tijms wrote:
Hi Stefan,

On Thursday, December 12, 2013, Stefan Guilhen wrote:
Hi Arun,

As there is no standard for the configuration of JASPI modules we have
historically used the security domain for that.

Indeed, if one wants to configure a SAM (or possibly other JASPIC module) for the entire application server outside of any deployed application in a declarative way, then a concept like the JBoss security domain is appropriate.

However, when the application registers its own local SAM (with wrappers) then such a security domain is not needed. None of the other application servers require something like it. The logic seems to be:

1. Check if there is a local SAM (matching app context id)
2. Check if there is a global SAM (using null as app context id)
3. Check if there is any proprietary mechanism in place (typically called realm, domain, zone, etc).

Because of 2. you can also more or less portably register/configure a SAM for the entire server by deploying a single .war with just a SAM and the aforementioned context listener and then just passing in null for the app context id. The spec defines that all contexts (all apps) on that server should then use that module.
 
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,

Would you happen to know which section of the spec exactly states this? I've read the spec a couple of times over, but couldn't really find anything. As the spec prose in case of the JASPIC spec is a bit difficult to digest I might have missed it.

I do know that in every other server there is no need at all to explicitly enable JASPIC. Just the mere act of using the standard factory to register the (wrapped) SAM is enough for those other servers.

 
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.

It would be absolutely great if WildFly could make the security domain thing optional for JASPIC. 

I interviewed a couple of developers about Java EE security and by far the biggest pain point seems to be with the (to them) awkward vendor specific xml files that are needed to get security going. (Note that while the other servers don't have the required valve like in JBoss EAP 6 or the security domain, they do have required vendor specific group to role mapping files which are just as painful).

The concept of a security domain also causes another issue in JBoss. The EJB spec does mention something about this for secured EJB beans (with a security interceptor via @RolesAllowed) but reasonably I think the spec intends this section to apply only for remote connections to a bean. 

But JBoss always consults this security domain, even for local calls and when the caller has already been authenticated (via JASPIC or otherwise). 

The problem is that the EJB security interceptor only knows how to deal with a JAAS login module, it doesn't know how to deal with JASPIC. Since JASPIC has no profile for an EJB "message exchange" this wouldn't work in a portable way no matter what.

All other servers seem to just propagate the existing authenticated identity and thus the case of a JASPIC login in the web layer followed by a call to an EJB with an @RolesAllowed works. In JBoss this always fails.

Also note that only the security interceptor tries to re-authenticate. The implementation of the isCallerInRole method on the EJBContext does not attempt this in JBoss and can thus theoretically work (but it too doesn't work in JBoss EAP 6.x due to a bug, which is again rather trivial to fix).

Kind regards,
Arjan Tijms


 

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 <[hidden email]> 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:


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]> wrote:
Hi Arjan,

These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.

Okay, sounds great!

I finally came around to add the tests for the new JASPIC 1.1 javax.servlet.http.registerSession feature. You can find it here: https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/register-session

I explained the feature some time ago on my blog at arjan-tijms.blogspot.com/2013/04/whats-new-in-java-ee-7s-authentication.html (note that the text is in part distilled from an email discussion I had about this feature with Ron Monzillo). The spec issue for this feature is at https://java.net/jira/browse/JASPIC_SPEC-3 and it's described in the JASPIC 1.1 spec under section Section 3.8.4.

Unfortunately WildFly fails the tests for this new feature; see https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/119/testReport/

Kind regards,
Arjan Tijms

 


 


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]> wrote:
These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.


Just wondering if there has been some progress in the meantime. The JASPIC tests unfortunately still don't run at all on WildFly.

I do have to update the tests to HtmlUnit though, and check whether there is or isn't an exception after a 403. The original tests were based on Drone and that one didn't threw an exception. GlassFish doesn't return a 403 by itself but just a blank response, so that's why I didn't catch this one earlier.

Anyway, it would be great if we can work together to get the tests to run.

Kind regards,
Arjan




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Tomaž Cerar-2
Hey,

this PR https://github.com/wildfly/wildfly/pull/5683 was merged yesterday, can you check if it fixes any of your problems?

--
tomaz


On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]> wrote:
Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]> wrote:
These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.


Just wondering if there has been some progress in the meantime. The JASPIC tests unfortunately still don't run at all on WildFly.

I do have to update the tests to HtmlUnit though, and check whether there is or isn't an exception after a 403. The original tests were based on Drone and that one didn't threw an exception. GlassFish doesn't return a 403 by itself but just a blank response, so that's why I didn't catch this one earlier.

Anyway, it would be great if we can work together to get the tests to run.

Kind regards,
Arjan




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
Hi,


On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]> wrote:
Hey,

this PR https://github.com/wildfly/wildfly/pull/5683 was merged yesterday, can you check if it fixes any of your problems?

I'll check it out, thanks! Any convenient place where I can download a nightly WildFly build?



 

--
tomaz


On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]> wrote:
Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]> wrote:
These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.


Just wondering if there has been some progress in the meantime. The JASPIC tests unfortunately still don't run at all on WildFly.

I do have to update the tests to HtmlUnit though, and check whether there is or isn't an exception after a 403. The original tests were based on Drone and that one didn't threw an exception. GlassFish doesn't return a 403 by itself but just a blank response, so that's why I didn't catch this one earlier.

Anyway, it would be great if we can work together to get the tests to run.

Kind regards,
Arjan




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Tomaž Cerar-2
You can find info about nightly builds here
https://community.jboss.org/thread/224262

but just wait a bit for new build that is currently building, that one will have changes you want.

--
tomaz


On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <[hidden email]> wrote:
Hi,


On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]> wrote:
Hey,

this PR https://github.com/wildfly/wildfly/pull/5683 was merged yesterday, can you check if it fixes any of your problems?

I'll check it out, thanks! Any convenient place where I can download a nightly WildFly build?



 

--
tomaz


On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]> wrote:
Hi,


On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]> wrote:
These are all valid points and I agree that our implementation could use some improvements. I'll create a document with the points that need to be addressed and I propose we discuss them further next week when Pedro returns from his vacations.


Just wondering if there has been some progress in the meantime. The JASPIC tests unfortunately still don't run at all on WildFly.

I do have to update the tests to HtmlUnit though, and check whether there is or isn't an exception after a 403. The original tests were based on Drone and that one didn't threw an exception. GlassFish doesn't return a 403 by itself but just a blank response, so that's why I didn't catch this one earlier.

Anyway, it would be great if we can work together to get the tests to run.

Kind regards,
Arjan




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Arun Gupta
Arjan,

5 test failures have gone down for now, jboss-web.xml is added to them for now.

Arun

On Thu, Jan 9, 2014 at 3:51 AM, Tomaž Cerar <[hidden email]> wrote:

> You can find info about nightly builds here
> https://community.jboss.org/thread/224262
>
> but just wait a bit for new build that is currently building, that one will
> have changes you want.
>
> --
> tomaz
>
>
> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <[hidden email]> wrote:
>>
>> Hi,
>>
>>
>> On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]>
>> wrote:
>>>
>>> Hey,
>>>
>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>> yesterday, can you check if it fixes any of your problems?
>>
>>
>> I'll check it out, thanks! Any convenient place where I can download a
>> nightly WildFly build?
>>
>>
>>
>>
>>>
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> These are all valid points and I agree that our implementation could
>>>>>> use some improvements. I'll create a document with the points that need to
>>>>>> be addressed and I propose we discuss them further next week when Pedro
>>>>>> returns from his vacations.
>>>>
>>>>
>>>>
>>>> Just wondering if there has been some progress in the meantime. The
>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>
>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>> there is or isn't an exception after a 403. The original tests were based on
>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>> earlier.
>>>>
>>>> Anyway, it would be great if we can work together to get the tests to
>>>> run.
>>>>
>>>> Kind regards,
>>>> Arjan
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
http://blog.arungupta.me
http://twitter.com/arungupta

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

Stefan Guilhen
I've put a PR for a commit that fixes the wrapping tests. Remaining
failures have been analysed and will be fixed soon.

On 01/09/2014 03:32 PM, Arun Gupta wrote:

> Arjan,
>
> 5 test failures have gone down for now, jboss-web.xml is added to them for now.
>
> Arun
>
> On Thu, Jan 9, 2014 at 3:51 AM, Tomaž Cerar <[hidden email]> wrote:
>> You can find info about nightly builds here
>> https://community.jboss.org/thread/224262
>>
>> but just wait a bit for new build that is currently building, that one will
>> have changes you want.
>>
>> --
>> tomaz
>>
>>
>> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <[hidden email]> wrote:
>>> Hi,
>>>
>>>
>>> On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]>
>>> wrote:
>>>> Hey,
>>>>
>>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>>> yesterday, can you check if it fixes any of your problems?
>>>
>>> I'll check it out, thanks! Any convenient place where I can download a
>>> nightly WildFly build?
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]>
>>>>>> wrote:
>>>>>>> These are all valid points and I agree that our implementation could
>>>>>>> use some improvements. I'll create a document with the points that need to
>>>>>>> be addressed and I propose we discuss them further next week when Pedro
>>>>>>> returns from his vacations.
>>>>>
>>>>>
>>>>> Just wondering if there has been some progress in the meantime. The
>>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>>
>>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>>> there is or isn't an exception after a 403. The original tests were based on
>>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>>> earlier.
>>>>>
>>>>> Anyway, it would be great if we can work together to get the tests to
>>>>> run.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
That's very good news Stefan!

I'll also take a look at the 403/Exception that you mentioned before. Indeed, HttpUnit throws an exception upon a 403 where Drone that I used for the original tests didn't. This will probably also fix a few test breakages.

Kind regards,
Arjan


On Thu, Jan 9, 2014 at 9:06 PM, Stefan Guilhen <[hidden email]> wrote:
I've put a PR for a commit that fixes the wrapping tests. Remaining
failures have been analysed and will be fixed soon.

On 01/09/2014 03:32 PM, Arun Gupta wrote:
> Arjan,
>
> 5 test failures have gone down for now, jboss-web.xml is added to them for now.
>
> Arun
>
> On Thu, Jan 9, 2014 at 3:51 AM, Tomaž Cerar <[hidden email]> wrote:
>> You can find info about nightly builds here
>> https://community.jboss.org/thread/224262
>>
>> but just wait a bit for new build that is currently building, that one will
>> have changes you want.
>>
>> --
>> tomaz
>>
>>
>> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <[hidden email]> wrote:
>>> Hi,
>>>
>>>
>>> On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]>
>>> wrote:
>>>> Hey,
>>>>
>>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>>> yesterday, can you check if it fixes any of your problems?
>>>
>>> I'll check it out, thanks! Any convenient place where I can download a
>>> nightly WildFly build?
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]>
>>>>>> wrote:
>>>>>>> These are all valid points and I agree that our implementation could
>>>>>>> use some improvements. I'll create a document with the points that need to
>>>>>>> be addressed and I propose we discuss them further next week when Pedro
>>>>>>> returns from his vacations.
>>>>>
>>>>>
>>>>> Just wondering if there has been some progress in the meantime. The
>>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>>
>>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>>> there is or isn't an exception after a 403. The original tests were based on
>>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>>> earlier.
>>>>>
>>>>> Anyway, it would be great if we can work together to get the tests to
>>>>> run.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 13 JASPIC tests failing on WildFly

arjan.tijms
Hi,

I fixed the tests so they don't throw exceptions anymore after a 403. Using a SNAPSHOT build from January 11, things start to get better now :)

[INFO] common ............................................ SUCCESS [1.422s]
[INFO] basic-authentication .............................. SUCCESS [5.315s]
[INFO] ejb-propagation ................................... FAILURE [5.010s]
[INFO] lifecycle ......................................... FAILURE [3.747s]
[INFO] register-session .................................. FAILURE [4.160s]
[INFO] wrapping .......................................... SUCCESS [3.739s]

ejb-propagation even partially succeeds. The authentication details are available in the public EJB bean (EJB bean without a security interceptor for @RolesAllowed), but access to a protected EJB (EJB bean with the security interceptor) fails.

This looks exactly like the bug in JBoss EAP 6.x. The security interceptor always tries to authenticate with the "security domain", where it expects a proprietary JBoss login module. I think the interceptor should just use the identity of the caller for local calls (calls to local EJB beans).

If I'm not mistaken, the entire reason to consult a security domain for every method call to an EJB bean is for remote EJB beans, not for local ones. I agree, the spec is not clear about this, but I think other servers indeed use the authenticated identity of the caller for local calls. See also the issue logged for EAP 6.x: https://issues.jboss.org/browse/SECURITY-746

lifecycle is also failing, but this should hopefully be rather simple to fix.

register-session may be a bit more tricky. I remember it took the GlassFish guys some effort.

Btw, there are some things that historically failed on JBoss for which I haven't created tests yet, like forwarding and including from a SAM, which are now mandatory for JASPIC 1.1 (but which the TCK probably doesn't test for either).

Kind regards,
Arjan Tijms














On Thu, Jan 9, 2014 at 10:28 PM, arjan tijms <[hidden email]> wrote:
That's very good news Stefan!

I'll also take a look at the 403/Exception that you mentioned before. Indeed, HttpUnit throws an exception upon a 403 where Drone that I used for the original tests didn't. This will probably also fix a few test breakages.

Kind regards,
Arjan


On Thu, Jan 9, 2014 at 9:06 PM, Stefan Guilhen <[hidden email]> wrote:
I've put a PR for a commit that fixes the wrapping tests. Remaining
failures have been analysed and will be fixed soon.

On 01/09/2014 03:32 PM, Arun Gupta wrote:
> Arjan,
>
> 5 test failures have gone down for now, jboss-web.xml is added to them for now.
>
> Arun
>
> On Thu, Jan 9, 2014 at 3:51 AM, Tomaž Cerar <[hidden email]> wrote:
>> You can find info about nightly builds here
>> https://community.jboss.org/thread/224262
>>
>> but just wait a bit for new build that is currently building, that one will
>> have changes you want.
>>
>> --
>> tomaz
>>
>>
>> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <[hidden email]> wrote:
>>> Hi,
>>>
>>>
>>> On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <[hidden email]>
>>> wrote:
>>>> Hey,
>>>>
>>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>>> yesterday, can you check if it fixes any of your problems?
>>>
>>> I'll check it out, thanks! Any convenient place where I can download a
>>> nightly WildFly build?
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <[hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <[hidden email]>
>>>>>> wrote:
>>>>>>> These are all valid points and I agree that our implementation could
>>>>>>> use some improvements. I'll create a document with the points that need to
>>>>>>> be addressed and I propose we discuss them further next week when Pedro
>>>>>>> returns from his vacations.
>>>>>
>>>>>
>>>>> Just wondering if there has been some progress in the meantime. The
>>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>>
>>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>>> there is or isn't an exception after a 403. The original tests were based on
>>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>>> earlier.
>>>>>
>>>>> Anyway, it would be great if we can work together to get the tests to
>>>>> run.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev