Errai: The browser as a platform

Wednesday, May 29, 2013


Security is important in any web application and with GWT this is not trivial. There are some well known security frameworks like PicketLink and Shiro, but they are hard to integrate into GWT because they are still request and URL based. So we decided that in true Errai fashion this should be easy.

The new security module is based on PicketLink, but can work with others as well, and integrates well with Errai's existing features like multi-page navigation and automatic data binding. To create a login page for example you'll need something like this:

There are a couple of things that are new here: on the @Page annotation we've introduced the notion of roles. A page can have multiple roles. "Default Page" is now also a page role. You can also define custom page roles in your application and use them to group your pages however you like. LoginPage is a special role that the security module defines. Errai-security will 'redirect' the user to the Login Page when they don't have enough rights to continue.

That raises the question: how do we specify that we need a logged in user for a specific operation or view? Well, we annotate:

This will 'redirect' the user to the login page when the user is not logged in or doesn't have the admin role. Now for those of you who are paying attention, you will have noticed that this is not very secure as this will all happen in the browser via JavaScript. Although the JavaScript is hard to read, an attacker could still be able to call the service even if he is not allowed. That is why the interceptors have server side equivalents that will throw exceptions instead of 'redirecting' the user.

On the server side, the interceptors are CDI interceptors and in order for them to activate you'll need to add them to your beans.xml.

When a user logs in or out, CDI events are fired. Of course, you can observe these events. Also, you can hide elements declaratively based on users' roles. For instance, hide a menu item in a navigation bar:

In this example the admin link is only shown when the user has this role. You'll need to remember to also annotate the Service methods that fetch data for this admin page as you can not rely on these client side checks alone.

Let me know what you think of it and what kind of features you would like to see in there.


  1. For clarity's sake, you could remove the unnecessary style attributes from the HTML template example!

  2. This looks great. One question though. It would be preferable not to use Errai-specific annotations for @RequireRoles etc. Has DeltaSpike still not gotten around to defining such annotations in the security module? Is JBoss still working with DeltaSpike? Seems to me stuff like this should be leveraging DeltaSpike (with Picketlink under the covers) and then just mixing in Errai magic on top to support the annotations client-side?

    1. The reason for the Errai specific annotations is to make sure that it works together with other Errai functionality like navigation and client interceptors. If you don't want to use them you loose the whole integration with the front-end. In the end that is what Errai-security is a front-end integration with the PicketLink backend.

    2. Hi Erik

      Security is a big thing. And expecting people to use PicketLink because they are are using errai is a big ask.

      We are using Apache Shiro, and we are really wanting to have a clean integration with Errai.

      Surely there is someway to have an interface that allows for an independence of security provider and Errai ?

    3. Hi Anton,

      Of course there is an interface that you could implement, right now I've have done only one e.g. PicketLink, but there could be other implementations as well. Which implementation is used can be selected at runtime by adding them as alternatives in the bean.xml.

      also see this fairly empty example of an alternative.

      Erik Jan

  3. Is it possible to integrate to LDAP