JASPIC improvements in WebLogic 12.1.3

-
Yesterday WebLogic 12.1.3 was finally released. First of all congratulations to the team at Oracle for getting this release out of the door! :)

Among the big news is that WebLogic 12.1.3 is now a mixed Java EE 6/EE 7 server by (optionally) supporting several Java EE 7 technologies like JAX-RS 2.0.

Next to this there are a ton of smaller changes and fixes as well. One of those fixes concerns the standard authentication system of Java EE (JASPIC). As we saw some time back, the JASPIC implementation in WebLogic 12.1.1 and 12.1.2 wasn't entirely optimal (to WebLogic's defense, very few JASPIC implementations were at the time).

One particular problem with JASPIC is that it almost can't be any different than that its TCK is rather incomplete; implementations that don't actually authenticate or which are missing the most basic functionality got certified in the past. For this purpose I have created a small set of tests that checks for the most basic capabilities. Note that these tests have since been contributed to Arun Gupta's Java EE 7 samples project, and have additionally been extended. Since those tests have Java EE 7 as a baseline requirement we unfortunately can't use them directly to test WebLogic 12.1.3.

For WebLogic 12.1.2 we saw the following results for the original Java EE 6 tests: 

[INFO] jaspic-capabilities-test .......................... SUCCESS [1.140s]
[INFO] jaspic-capabilities-test-common ................... SUCCESS [1.545s]
[INFO] jaspic-capabilities-test-basic-authentication ..... FAILURE [7.533s]
[INFO] jaspic-capabilities-test-lifecycle ................ FAILURE [3.825s]
[INFO] jaspic-capabilities-test-wrapping ................. FAILURE [3.803s]
[INFO] jaspic-capabilities-test-ejb-propagation .......... SUCCESS [4.624s]

FAILURES:

testUserIdentityIsStateless(org.omnifaces.jaspictest.BasicAuthenticationStatelessIT
java.lang.AssertionError: User principal was 'test', but it should be null here. The container seemed to have remembered it from the previous request.
 at org.omnifaces.jaspictest.BasicAuthenticationStatelessIT.testUserIdentityIsStateless(BasicAuthenticationStatelessIT.java:137)

testPublicPageNotRememberLogin(org.omnifaces.jaspictest.BasicAuthenticationPublicIT)java.lang.AssertionError: null
 at org.omnifaces.jaspictest.BasicAuthenticationPublicIT.testPublicPageNotLoggedin(BasicAuthenticationPublicIT.java:44)
 at org.omnifaces.jaspictest.BasicAuthenticationPublicIT.testPublicPageNotRememberLogin(BasicAuthenticationPublicIT.java:64)

testBasicSAMMethodsCalled(org.omnifaces.jaspictest.AuthModuleMethodInvocationIT)
java.lang.AssertionError: SAM methods called in wrong order
 at org.omnifaces.jaspictest.AuthModuleMethodInvocationIT.testBasicSAMMethodsCalled(AuthModuleMethodInvocationIT.java:54)

testResponseWrapping(org.omnifaces.jaspictest.WrappingIT)
java.lang.AssertionError: Response wrapped by SAM did not arrive in Servlet.
 at org.omnifaces.jaspictest.WrappingIT.testResponseWrapping(WrappingIT.java:53)

testRequestWrapping(org.omnifaces.jaspictest.WrappingIT)
java.lang.AssertionError: Request wrapped by SAM did not arrive in Servlet.
 at org.omnifaces.jaspictest.WrappingIT.testRequestWrapping(WrappingIT.java:45)

WebLogic 12.1.3 does quite a bit better as we now see the following: 

[INFO] jaspic-capabilities-test .......................... SUCCESS [1.172s]
[INFO] jaspic-capabilities-test-common ................... SUCCESS [1.802s]
[INFO] jaspic-capabilities-test-basic-authentication ..... FAILURE [6.811s]
[INFO] jaspic-capabilities-test-lifecycle ................ SUCCESS [3.847s]
[INFO] jaspic-capabilities-test-wrapping ................. SUCCESS [3.777s]
[INFO] jaspic-capabilities-test-ejb-propagation .......... SUCCESS [4.800s]

FAILURES:

testUserIdentityIsStateless(org.omnifaces.jaspictest.BasicAuthenticationStatelessIT)
java.lang.AssertionError: User principal was 'test', but it should be null here. The container seemed to have remembered it from the previous request.
 at org.omnifaces.jaspictest.BasicAuthenticationStatelessIT.testUserIdentityIsStateless(BasicAuthenticationStatelessIT.java:137)

In particular WebLogic 12.1.1 and 12.1.2 didn't support request/response wrapping (a feature that curiously not a single server supported), called a lifecycle method at the wrong time (the method secureResponse was called before a Servlet was invoked instead of after) and remembered the username of a previously logged-in user (within the same session, but JASPIC is supposed to be stateless).

As of WebLogic 12.1.3 the lifecycle method is called at the correct moment and request/response wrapping is actually possible. This now brings the total number of servers where the request/response can be wrapped to 3 (GlassFish since 4.0 and JBoss since WildFly 8 can also do this).

It remains a curious thing that the JASPIC TCK seemingly catches so few issues, but slowly the implementations of JASPIC are getting better. The JASPIC improvements in WebLogic 12.1.3 may not have made the headlines, but it's another important step for Java EE authentication.

Arjan Tijms

Comments

Post a Comment

Popular posts from this blog

Jakarta EE Survey 2022

-
At OmniFaces we poll the community from time to time and again about Jakarta EE (previously Java EE) and related technologies. With the transfer of Java EE to Jakarta EE now fully completed and Jakarta EE 10 released , people are now starting to think about Jakarta EE 11 , the second Jakarta EE feature release. As such it's a good time to poll the community again. This year we're doing so in cooperation with OmniFish . In the 2022 edition, there are 4 categories of questions again: Current usage of Jakarta EE Servlet containers APIs related to Jakarta EE The future of Jakarta EE Compared to 2020, we simplified some of the questions once more; again omitting some of the less popular options to make it more manageable. We kept the questions about the future of Jakarta EE and MP together as this issue still isn't resolved. We also ask about the preferred Jakarta EE cadence. As Jakarta EE 10 is the first feature release, we haven't really established a cade...
Read more

Implementing container authentication in Java EE with JASPIC

-
This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more.   Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR...
Read more

Counting the rows returned from a JPA query

-
Despite being almost ten years old, the JPA specification to this day has rather poor support for basic paging/sorting/filtering. Paging/sorting/filtering is used in a lot of (CRUD) applications where the result from a query is shown in a table, and where the user can scroll through the results one page at a time, and where this result can be sorted by clicking on any of the table column headers. In order to support this a number of things are generally needed: The total number of rows (or entities) in the full result must be known There should be support for an offset in the full result and a limit for the amount of rows that will be obtained The column (attribute) on which to sort must be dynamically added to the query Search expressions must be dynamically added to the query As it appears, only offset/limit is directly supported in JPA. A sorting column can only be added dynamically when using the overly verbose and hard to work with Criteria API. Search expressions...
Read more