Apache Shiro vs Java EE native APIs

Question

What advantages are there by going to Apache Shiro, and leaving Java EE's native APIs for security and session management?

I found that all security roles and sessions can be done in Apache Shiro but the same thing can also be done using Java EE security without any external dependency jars.

So suggest me some pros and cons of going to Apache Shiro.

Answer 1

I am biased of course (I'm a committer on the Apache Shiro project), so take this as you see fit, but here are my opinions:

• Java EE Security does not support container-independent session clustering options out of the box (Shiro does).

• Shiro was designed from its inception to work in POJO/Dependency Injection environments. It uses interface-driven design and provides many more hooks for customization than traditional Java EE security environments (e.g. how do you show how many users are currently logged in to your site with Java EE security? Shiro can help you show this).

• Shiro is fully portable across any application environment. If you use Java EE vendor-specific security customizations, those would not be portable (e.g this StackOverflow question shows that switching to JBoss might solve the user's security problem - an unsettling answer IMO).

• In the same vein as server-specific customizations, many Java EE security tutorials, articles and blog articles show you user-interface based configuration, which addresses things in different ways across platforms and can be frustrating to re-learn if you switch. Also, Java EE config often requires XML. I prefer a single, non-verbose text config format that I can use anywhere (shiro.ini is nice, but people also configure shiro with groovy, yaml, etc).

• Shiro was designed to work in any application environment. Java EE security was designed, well - for Java EE only. At least when you learn Shiro, you can leverage that knowledge in any JVM-based application (Spring, Guice, Java EE, command line, etc), not just Java EE apps.

HTH!

Les