High level Java security framework

Question

What security framework do you use in your Java projects?

I used Spring Security and Apache Shiro and they both look immature.

Spring Security flaws:

1. no native support for permissions;
2. no ability to use explicitly in Java code (sometimes it's necessary);
3. too much focused on classic (non AJAX) web applications.

Apache Shiro flaws:

1. bugs in final release (like the problem with Spring integration);
2. no support for OpenID and some other widely used technologies;
3. performance issues reported.

There is also lack of documentation for both of them.

Maybe most of the real projects develop their own security frameworks?

Answer 1

As for Apache Shiro:

I'm not sure why you've listed the things you did:

1. Every project in the world has release bugs, without question. The big key here however is that Shiro's team is responsive and fixes them ASAP. This is not something to evaluate a framework on, otherwise you'd eliminate every framework, including any you write yourself.
2. OpenID support will be released shortly in Shiro 1.2 - maybe a month out?.
3. What performance issues? No one has ever reported performance issues to the dev list, especially since the caching support in Shiro is broad and first-class. Without clarifications or references, this comes across as FUD.
4. Documentation now is really good actually - some of the best in Open Source that I've seen lately (it was re-worked 2 weeks ago). Do you have specific examples of where it falls short for you?

I'd love to help, but your concerns are generalizations that aren't supported by references or concrete examples. Maybe you could represent specific things that your project needs that you've fail to accomplish thus far?

Apache Shiro continues to be the most flexible and easiest to understand security framework for Java and JVM languages there is - I doubt you'll find better.

But, above all, and I mean this with all sincerity, please don't write your own security framework unless you plan on putting a ridiculous amount of time into it. Nearly every company I've ever seen that tries to do this themselves fails miserably. It is really hard to get 'right' (and secure). Trust me - after writing one for 8 years, that's one thing I'm absolutely sure of :)

Anyway, feel free to join the Shiro user list and you're sure to find that the community is happy and willing to work through whatever issues you may have. You'll find that we take care of the people that ask questions and do our best to help out.

HTH!

Answer 2

My current projects use SpringSecurity and involve doing all three things you claim to be flaws in SpringSecurity:

• The projects implement fine-grained access rules that go beyond simple ROLEs, and variously involve state of domain objects, extra request parameters, and so on. These are implemented using custom "access policy objects" that get called within my MVC controllers. However, access check failures are handed back to SpringSecurity by throwing the relevant exception. (These could have been implemented as standard SpringSecurity method-level interceptors, but the checks typically involve examining domain objects.)

• The projects support both web and AJAX access, and deal with access failures differently for the two cases. This is done by writing some custom Authentication entrypoint components for SpringSecurity that choose between different authentication behaviors depending on the request URL, etc.

In other words, it can be done ...

Having said that, I agree with you on a couple of points:

• It is not easy to wire this up kind of thing. I kept on running into roadblocks when using the <http> element and its associated configurer. Like ... you want it to use a different version of component X. But to do that you have to replace Y, Z, P and Q as well.

• The documentation is really sparse, and not helpful if you are trying to do something out of the ordinary.