[wildfly-dev] 13 JASPIC tests failing on WildFly
Stefan Guilhen
sguilhen at redhat.com
Thu Dec 12 12:57:44 EST 2013
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
> <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/160d83d0/attachment.html
More information about the wildfly-dev
mailing list