<div dir="ltr"><pre style="color:rgb(0,0,0)">Hi,</pre><pre><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I had stressed for standardization of the JASPI configuration. The spec <br>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 <br>any app server.<br></blockquote><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">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).</div>
<div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">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:</div>
<div style="color:rgb(0,0,0)"><br></div><div><font color="#000000">@WebListener
public class SamAutoRegistrationListener extends BaseServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
JaspicUtils.registerSAM(sce.getServletContext(), new TestServerAuthModule());
}
}<br></font></div><div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">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 ;)</font></div>
<div><font color="#000000"><br></font></div><div><font color="#000000">Kind regards,</font></div><div><font color="#000000">Arjan Tijms</font></div><div><font color="#000000"><br></font></div><div style="color:rgb(0,0,0)">
<br></div><div style="color:rgb(0,0,0)"> </div><blockquote class="gmail_quote" style="color:rgb(0,0,0);margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That was the goal of the spec but I don't think it really has reached <br>that potential.
As Stefan said, let us wait for all the JASPI related PRs to be merged <br>before looking into<br>the failures.</blockquote><font color="#000000">
On 12/11/2013 08:12 AM, Arun Gupta wrote:
></font><i style="color:rgb(0,0,0)"> I changed the <security-domain> to:
</i><font color="#000000">></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> <security-domain name="jaspitest" cache-type="default">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> <authentication-jaspi>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> <login-module-stack name="dummy">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> <login-module code="Dummy" flag="optional"/>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> </login-module-stack>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> <auth-module
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> flag="required"/>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> </authentication-jaspi>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> </security-domain>
</i><font color="#000000">></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> and getting more failures. Will wait for the PR to be merged.
</i><font color="#000000">></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> Arun
</i><font color="#000000">></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">></font><i style="color:rgb(0,0,0)"> On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">sguilhen at redhat.com</a>> wrote:
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> Actually they seem to be registering their own AuthConfigProvider, in
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> which case the dummy domain setup is fine (configuring our auth-module
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> impl won't do anything as their provider will register their own test
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> module), so disregard my previous e-mail.
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> Note that there is a pending pull request
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> (<a href="https://github.com/wildfly/wildfly/pull/5558/">https://github.com/wildfly/wildfly/pull/5558/</a>) that seems to fix a few
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> of the issues seen in the tests. Lets run the tests again once the PR is
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> merged to and see where we stand.
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> Stefan
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>></font><i style="color:rgb(0,0,0)"> On 12/11/2013 10:52 AM, Stefan Guilhen wrote:
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> If you are using the security domain as mentioned in the commit any
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> authentication will fail because there is no "dummy" auth-module. I
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> couldn't find the WildFly log but there must be exceptions there
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> indicating it was not possible to load the auth-module class.
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> Try setting the auth module in the security domain to
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> <auth-module
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule"
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> flag="required"/>
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> And see how it goes.
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> Stefan
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>></font><i style="color:rgb(0,0,0)"> On 12/10/2013 10:16 PM, Arun Gupta wrote:
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at:
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> <a href="https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic">https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic</a>
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> 13 of them are failing with WildFly as shown at:
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> <a href="https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/">https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/98/testReport/</a>
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> 21 of these tests are passing on GlassFish as shown at:
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> <a href="https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/">https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20GlassFish-cb/47/testReport/</a>
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> JASPIC support in WildFly is reported "broken" as mentioned at:
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> <a href="https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724">https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b453d7dde985debc08d80b09efcf724</a>
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> Adding a new <security-domain> as mentioned in the above commit
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> message only marginally improves the results.
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> Do you see any basic configuration issue with OOTB WildFly for running
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> these tests ?
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)">
</i><font color="#000000">>>>></font><i style="color:rgb(0,0,0)"> Arun
</i><font color="#000000">>>></font></pre></div>