[wildfly-dev] 13 JASPIC tests failing on WildFly

Thu Dec 12 06:31:16 EST 2013

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 <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:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131212/e9601d81/attachment-0001.html 