Java EE Security: JASPIC / JAAS or apply a Security Framework? (Glassfish 3)

Question

I am currently using Oracle ADF (which is an end-to-end Java EE framework) for building my web applications and GlassFish 3.1 as application server.

The latter supports JAAS (declarative inside its admin console). So, I have created a security realm and mapped them with the roles declared in a configuration file and use JAAS to implement the authorization and authentication security features. Everything fine, until now! This past weeks I have been researching on Java EE security.

What I've found is that JAAS is good enough if you stick with "basic" security. Moreover, it seems that JAAS (as part of the Java Security Framework) was meant just for Java SE (but since Java EE is built on Java SE, some of it’s modules are being reused, such as LoginMethod and Callbacks).

Then, I've found many posts about JASPIC, finding out that it can be implemented only by a programmatic manner (not a problem) and it's not yet fully supported by app servers vendors, and tried to make a comparison between both. Even if JASPIC1.1 release had resolved some issues, like:

The container will however not fully remember the authentication. The SAM is still called at each request, and the SAM still has to re-authenticate

(it doesn't sound so good to me).

Then, I've passed on looking for integrating some security framework. The most famous ones seems to be "Spring" and "Shiro". Of course each one of them has it's own characteristics (may be the first is more suitable on a specific situation while the second in another). What's more important to me at the more are:

• Authentication
• Authorization
• Session Management (and possibly, encryption)

But, everywhere I found contradictory conclusions. The result: I'm more confused now then before searching.

I am just a novice in topics like security, and moreover I am a developer (I have stuff to implement), so it's kinda hard to keep up to date with every new release and the progress on security seems to keep going on every day galloping.

I'd like some facts based on personal experience if possible. Every hint or suggestion is appreciated. I want to be sure I'm confident before taking the implementation step.

Answer 1

JASPIC is the one technology that being a part of Java EE integrates really well with it.

The fact that JASPIC authentication modules don't automatically remember a session is an advantage too as it makes them suitable for stateless applications too (think APIs such as JAX-RS). When you authenticate and do want sessions, then just put the result (username + groups) into the session. Then at the start of each "validateRequest" method do a quick check if there's anything in the session and if so give these to the container again. No need to authenticate from scratch and certainly no need to remember any password!

Shiro and Spring Security are very full featured frameworks. You can barely compare that to JASPIC which is very low level and basic. Both Spring and Shiro don't perfectly integrate with Java EE. Spring Security is often said to be more complex than Shiro.

Hope this helps

Answer 2

The Servlet profile of JASPIC requires that the configured (for the app) Server Authentication module(s) (SAM) be called on every request; exactly so that the SAM will be able to manage authentication sessions (should that be desired)

The profile also supports the case, where a SAM is configured to perform authentication, but then wishes to delegate authentication session management to the encompassing container, which is enabled by the used of the registerSession callback property.

Also as noted by Mike Braun, the profile also supports a stateless mode wrt to authentication sessions, and is fully integrated with the container authorization system; such that JASPIC authentication must occur when the target request is covered by an authorization constraint (such as would be defined in web.xml or by use of the ServletSecurity annotation).

The JASPIC defined Callbacks and the container provided Callback handler, allow a portable SAM to set the container caller principal, to consult the container's user registry for password validation and group assignment, etc.