<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Arjan,<br>
      <br>
      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.<br>
      <br>
      Cheers,<br>
      Stefan<br>
      <br>
      On 12/12/2013 09:31 AM, arjan tijms wrote:<br>
    </div>
    <blockquote
cite="mid:CAE=-AhDGAeEVY7drXjTDAHsWYMhYyoMhFWRELGh_P7b7OOy7TQ@mail.gmail.com"
      type="cite">Hi Stefan,<br>
      <br>
      On Thursday, December 12, 2013, Stefan Guilhen wrote:<br>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Arun,<br>
        <br>
        As there is no standard for the configuration of JASPI modules
        we have<br>
        historically used the security domain for that.</blockquote>
      <div><br>
      </div>
      <div>Indeed, if one wants to configure a SAM (or possibly other
        JASPIC&nbsp;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.</div>
      <div><br>
      </div>
      <div>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:</div>
      <div><br>
      </div>
      <div>1. Check if there is a local SAM (matching app context id)</div>
      <div>2. Check if there is a global SAM (using null as app context
        id)</div>
      <div>3. Check if there is any proprietary mechanism in place
        (typically called realm, domain, zone, etc).</div>
      <div><br>
      </div>
      <div>Because of 2. you can also&nbsp;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.</div>
      <div>&nbsp;</div>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">The descriptor
        is needed<br>
        to link the web application to the security domain that contains
        the<br>
        JASPI configuration and the container uses the security domain
        config to<br>
        determine if JAAS or JASPI will be used to authenticate users.<br>
        <br>
        Also note that in WF (and all previous JBoss AS versions) JASPI
        is not<br>
        enabled by default as the specs don't require us to do that,</blockquote>
      <div><br>
      </div>
      <div>Would you happen to know which section of the spec exactly
        states this? I've read the spec a&nbsp;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.</div>
      <div><br>
      </div>
      <div>I do know that in every other server there is no need at
        all&nbsp;to explicitly enable JASPIC. Just the mere act of using the
        standard factory to register the (wrapped) SAM is enough for
        those other&nbsp;servers.</div>
      <br>
      <div>&nbsp;</div>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">so we rely<br>
        on this security domain config to enable it. I've had a
        discussion with<br>
        Pedro - dev who implemented the JASPI mechanism for WildFly - a
        couple<br>
        of months ago and we thought the configuration needed to be
        revisited<br>
        but we have never had the time to do that.</blockquote>
      <div><br>
      </div>
      <div>It&nbsp;would be absolutely great if WildFly could make the
        security domain thing optional for JASPIC.&nbsp;</div>
      <div><br>
      </div>
      <div>I interviewed a couple of developers about Java EE security
        and by far the biggest pain point seems&nbsp;to be with the (to them)
        awkward vendor specific xml files that are needed to get
        security going. (Note that while&nbsp;the other servers don't have
        the required valve like in JBoss EAP 6 or the security domain,
        they do have required vendor specific&nbsp;group to role mapping
        files which are&nbsp;just as painful).</div>
      <div><br>
      </div>
      <div>The concept of a security domain also causes another issue in
        JBoss. The EJB spec does&nbsp;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&nbsp;for remote connections to a bean.&nbsp;</div>
      <div><br>
      </div>
      <div>But JBoss always consults this security domain, even for
        local calls and when the caller has already been authenticated
        (via JASPIC or otherwise).&nbsp;</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>All other servers seem to just propagate the existing
        authenticated identity and thus the case of a JASPIC login in
        the web layer&nbsp;followed by a call to an EJB with an @RolesAllowed
        works. In JBoss this always fails.</div>
      <div><br>
      </div>
      <div>Also note that only the security interceptor tries to
        re-authenticate. The implementation of the&nbsp;isCallerInRole
        method&nbsp;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&nbsp;due to a bug, which is again rather trivial to fix).</div>
      <div><br>
      </div>
      <div>Kind regards,</div>
      <div>Arjan Tijms</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>&nbsp;</div>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <br>
        Cheers,<br>
        Stefan<br>
        <br>
        On 12/11/2013 11:50 PM, Arun Gupta wrote:<br>
        &gt; Stefan,<br>
        &gt;<br>
        &gt; Thanks, waiting for the PR!<br>
        &gt;<br>
        &gt; Are these JBoss-specific deployment descriptors required
        because the<br>
        &gt; spec is under specified ?<br>
        &gt;<br>
        &gt; Arun<br>
        &gt;<br>
        &gt; On Wed, Dec 11, 2013 at 5:26 PM, Stefan Guilhen &lt;<a
          moz-do-not-send="true">sguilhen@redhat.com</a>&gt; wrote:<br>
        &gt;&gt; Indeed, I've taken a look at your tests and the
        solution is pretty clean<br>
        &gt;&gt; although I have to agree with Anil that having a
        standard for the config<br>
        &gt;&gt; would help a lot.<br>
        &gt;&gt;<br>
        &gt;&gt; As a side note, the results are not as bad as they
        seem. The javaee7-samples<br>
        &gt;&gt; project is missing a few jboss-web.xml descriptors and
        there's also an issue<br>
        &gt;&gt; with HttpUnit throwing an exception that prevents
        certain tests from<br>
        &gt;&gt; completing. I'm taking a look into these issues and
        will send a PR for the<br>
        &gt;&gt; javaee7-samples project with a few fixes. I believe we
        will see much better<br>
        &gt;&gt; numbers after that.<br>
        &gt;&gt;<br>
        &gt;&gt; Stefan<br>
        &gt;&gt;<br>
        &gt;&gt; On 12/11/2013 06:51 PM, arjan tijms wrote:<br>
        &gt;&gt;<br>
        &gt;&gt; Hi,<br>
        &gt;&gt;&gt; I had stressed for standardization of the JASPI
        configuration. &nbsp;The spec<br>
        &gt;&gt;&gt; lead wanted to keep it open. This was early days of
        the JSR.<br>
        &gt;&gt;&gt; I seriously doubt you can have auth modules written
        once and deploy on<br>
        &gt;&gt;&gt; any app server.<br>
        &gt;&gt; Actually it doesn't seem to be that bad. Using the
        programmatic registration<br>
        &gt;&gt; method (which is the only standardized method) pretty
        much every app server<br>
        &gt;&gt; installs the SAM just fine (Geronimo is the sole
        exception).<br>
        &gt;&gt;<br>
        &gt;&gt; Yes, the first time it's a hassle that you have to code
        the wrapper<br>
        &gt;&gt; AuthConfigProvider, ServerAuthConfig etc types, but
        once you hide that away<br>
        &gt;&gt; inside a utility method it's a one liner to install a
        SAM from a<br>
        &gt;&gt; ServletContextListener. This is exactly what the tests
        that I committed do:<br>
        &gt;&gt;<br>
        &gt;&gt; @WebListener<br>
        &gt;&gt; public class SamAutoRegistrationListener extends
        BaseServletContextListener<br>
        &gt;&gt; {<br>
        &gt;&gt;<br>
        &gt;&gt; &nbsp; &nbsp; &nbsp;@Override<br>
        &gt;&gt; &nbsp; &nbsp; &nbsp;public void contextInitialized(ServletContextEvent
        sce) {<br>
        &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp;JaspicUtils.registerSAM(sce.getServletContext(), new<br>
        &gt;&gt; TestServerAuthModule());<br>
        &gt;&gt; &nbsp; &nbsp; &nbsp;}<br>
        &gt;&gt; }<br>
        &gt;&gt;<br>
        &gt;&gt; It's perhaps a shame there's no declarative
        alternative, but this method<br>
        &gt;&gt; itself is IMHO not wrong per se. The Servlet spec
        defines similar APIs for<br>
        &gt;&gt; registering Servlets and Filters programmatically.<br>
        &gt;&gt;<br>
        &gt;&gt; After working with JASPIC rather intensively for well
        over a year now I can<br>
        &gt;&gt; say that it does work in a portable way. The main issue
        is the multitude of<br>
        &gt;&gt; bugs in the various implementations and/or
        implementations just not doing<br>
        &gt;&gt; what's in the spec.<br>
        &gt;&gt;<br>
        &gt;&gt; For instance, secureResponse should be called AFTER the
        resource (e.g. a<br>
        &gt;&gt; Servlet or JSP page) is invoked, but some
        implementations erroneously call<br>
        &gt;&gt; it before the resource is invoked. This makes it
        impossible to use this<br>
        &gt;&gt; method for a SAM that has to be portable. The spec is
        clear on this topic,<br>
        &gt;&gt; but the app servers just don't always do the right
        thing.<br>
        &gt;&gt;<br>
        &gt;&gt; Some aspects of the spec are just ignored by pretty
        much all servers, like<br>
        &gt;&gt; the ability of a SAM to wrap the request and response
        objects (just like a<br>
        &gt;&gt; Servlet Filter can do). For the open source servers it
        can be seen that this<br>
        &gt;&gt; functionality is not even attempted. Ironically,
        GlassFish does attempt it,<br>
        &gt;&gt; but due to a rather complicated bug it eventually fails
        to deliver the<br>
        &gt;&gt; wrapped request to the resource, while it does deliver
        the wrapped response<br>
        &gt;&gt; correctly.<br>
        &gt;&gt;<br>
        &gt;&gt; So IMHO 90% of the non-portability of a SAM is just due
        to implementation<br>
        &gt;&gt; bugs. Many of them are rather trivial to fix. Hopefully
        having a series of<br>
        &gt;&gt; tests can help remedy this issue ;)<br>
        &gt;&gt;<br>
        &gt;&gt; Kind regards,<br>
        &gt;&gt; Arjan Tijms<br>
        &gt;&gt;<br>
        &gt;&gt;<br>
        &gt;&gt;<br>
        &gt;&gt;&gt; That was the goal of the spec but I don't think it
        really has reached<br>
        &gt;&gt;&gt; that potential.<br>
        &gt;&gt;&gt; As Stefan said, let us wait for all the JASPI
        related PRs to be merged<br>
        &gt;&gt;&gt; before looking into<br>
        &gt;&gt;&gt; the failures.<br>
        &gt;&gt; On 12/11/2013 08:12 AM, Arun Gupta wrote:<br>
        &gt;&gt;&gt; I changed the &lt;security-domain&gt; to:<br>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>