Arjan Tijms' Weblog

In Java EE security two artefacts play a major role, the authentication mechanism and the identity store . The authentication mechanism is responsible for interacting with the caller and the environment. E.g. it causes a UI to be rendered that asks for details such as a username and password, and after a postback retrieves these from the request. As such it's roughly equivalent to a controller in the MVC architecture. Java EE has standardised 4 authentication mechanisms for a Servlet container, as well as a JASPIC API profile to provide a custom authentication mechanism for Servlet (and one for SOAP, but let's ignore that for now). Unfortunately standard custom mechanisms are only required to be supported by a full Java EE server, which means the popular web profile and standalone servlet containers are left in the dark. [update: since EE 8 Web Profile supports JASPIC too] Servlet vendors can adopt the standard API if they want and the Servlet spec even encourages th...

JBoss WildFly has a rather good implementation of JASPIC , the Java EE standard API to build authentication modules. Unfortunately there's one big hurdle for using JASPIC on JBoss WildFly; it has to be activated. This activation is somewhat of a hack itself, and is done by putting the following XML in a file called standalone.xml that resides with the installed server: <security-domain name="jaspitest" cache-type="default"> <authentication-jaspi> <login-module-stack name="dummy"> <login-module code="Dummy" flag="optional"/> </login-module-stack> <auth-module code="Dummy"/> </authentication-jaspi> </security-domain> UPDATE Dec 23, 2015: Since WildFly 10rc5 the "jaspitest" domain is included by default in standalone.xml and no longer has to be added manually. For JBoss EAP 7 beta1 and earlier this is still needed a...

Iterating components in JSF such as h:dataTable and ui:repeat have the DataModel class as their native input type. Other datatypes such as List are supported, but these are handled by build-in wrappers; e.g. an application provided List is wrapped into a ListDataModel . While JSF has steadily expanded the number of build-in wrappers and JSF 2.3 has provided new ones for Map and Iterable , a long standing request is for users (or libraries) to be able to register their own wrappers. JSF 2.3 will now (finally) let users do this. The way this is done is by creating a wrapper DataModel for a specific type, just as one may have done years ago when returning data from a backing bean, and then annotating it with the new @FacesDataModel annotation. A “forClass” attribute has to be specified on this annotation that designates the type this wrapper is able to handle. The following gives an abbreviated example of this: @FacesDataModel(forClass = MyCollection.class) public class M...

We're proud to announce that today we've released OmniFaces 2.1. OmniFaces is a utility library for JSF that provides a lot of utilities to make working with JSF much easier. OmniFaces 2.1 is the second release that will depend on JSF 2.2 and CDI 1.1 from Java EE 7. Since Java EE 7 availability remains somewhat scarce, we maintain a no-frills 1.x branch for JSF 2.0 (without CDI) as well. The easiest way to use OmniFaces 2.1 is via Maven by adding the following to pom.xml: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.1</version> </dependency> Alternatively the jars files can be downloaded directly . A complete overview of all that's new can be found on the what's new page , and some more details can be found in BalusC's blogpost about this release . As usual the release contains an assortment of new features, some changes and a bunch of fixes. One p...

In a previous article we took a look at an obscure Java EE application server that's only known in Korea and virtually unknown everywhere else. Korea is not the only country that has a national application server though. Japan is the other country. In fact, it has not one, but three obscure application servers. These Japanese servers, the so-called obscure 3, are so unknown outside of Japan that major news events like a Java EE 7 certification simply just does not make it out here . Those servers are the following: NEC WebOTX Hitachi Application Server Fujitsu Interstage AS In this article we're going to take a quick look at the first one of this list: NEC WebOTX. While NEC does have an international English page where a trial can be downloaded it only contains a very old version of WebOTX; 8.4, which implements Java EE 5. This file is called otx84_win32bitE.exe and is about 92MB in size. As with pretty much all of the Asian application servers, the native...

We are proud to announce that OmniFaces 2.1 release candidate 1 has been made available for testing. OmniFaces 2.1 is the second release that will depend on JSF 2.2 and CDI 1.1 from Java EE 7. Since Java EE 7 availability remains somewhat scarce, we maintain a no-frills 1.x branch for JSF 2.0 (without CDI). For this branch we've simultaneously released a release candidate as well: 1.11-RC1. A full list of what's new and changed is available here . OmniFaces 2.1 RC1 can be tested by adding the following dependency to your pom.xml: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.1-RC1</version> </dependency> Alternatively the jars files can be downloaded directly . For the 1.x branch the coordinates are: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>1.11-RC1</version...

In this article we take a look at the latest April 2015 beta version of IBM's Liberty server, and specifically look at how well it implements the Java EE authentication standard JASPIC. The initial version of Liberty implemented only a seemingly random assortment of Java EE APIs, but the second version that we looked at last year officially implemented the (Java EE 6) web profile. This year however the third incarnation is well on target to implement the full profile of Java EE 7. This means IBM's newer and much lighter Liberty (abbreviated WLP), will be a true alternative for the older and incredibly obese WebSphere (abbreviated WAS) where it purely concerns the Java EE standard APIs. From having by far the most heavyweight server on the market (weighing in at well over 2GB), IBM can now offer a server that's as light and small as various offerings from its competition. For this article we'll be specifically looking at how well JASPIC works on Liberty. Please ta...