When to move from Container managed security to al

问题:

I am trying to secure my application which is built using JSF2.0.

I am confused about when do people choose to go with security alternatives like Shiro, Spring Security or owasp's esapi leaving behind container managed security. Having seen some of related questions on Stack Overflow, where I realized that container based security was more preferred by JSF developers in past. But I have also been strongly recommended to use Apache Shiro. I am novice in terms of the security issues and have no idea what may be the relevant issues & how to deal with them. Therefore I'm looking for something that handles most of the security issues through its default settings/ on its own.

In terms of my application requirements, I have a social application where users with different roles have access to different set of pages and can use different levels of functionality on those pages based on their roles.

In that case what do you think could be a good option for me to go with ?

I personally have been convinced to opt Shiro since it is easy to use and takes care of most of the things for the novice.

回答1:

I know exactly nothing about Apache Shiro except as follows, but what you have quoted comes practically verbatim from their Web page, which contains several mis-statements such as '[JAAS] required static definitions that only programmers could change', and 'JAAS is tied too heavily tied to virtual machine-level concerns', and the implication that JAAS isn't about users and roles, which is simply false. I would want a lot of convincing to move away from container managed security. It's part of the Servlet Specification, so it has to be supported by any container; it's well understood; it is supported by JDK classes with no 3rd parties; ... and it works for me ;-)

回答2:

What I like about Shiro is that it's really ease to setup permission based security. JAAS is heavily role based which is a granularity that ironically is more useful to consumer webapps than to enterprise apps (as we can notice from your requirements).

• It's common for an application server to provide some services on top of JAAS, like single sign on, built in loginmodules, etc, so sometimes when permission granularity isn't a requirement, you should go for JAAS.

• Last time I checked Shiro also didn't supported mutual ssl authentication (using digital certificates), but you probably wouldn't be using that...

• If you use Shiro your app will probably be more portable between application servers / servlet containers (oh, the irony!), as JavaEE security configuration tends to be vendor specific for most non-trivial setups.

All in all, based on the requirements you specified:

• Using an AppServer (GlassFish, JBoss): JAAS (ootb authc/authz, built-in loginmodules)
  
• Using a Servlet Container (Jetty/Tomcat): Shiro (easier to setup and use)

Hope it helps :)

回答3:

I have decided that SpringSecurity (SS) is going to be our Authentication and Authorization framework. Mainly because SS does OpenID and OAuth. I will have to customize it though for the permissions/group/user/entity system quite a bit. I plan on doing authorization at the 'EntityManager/Entity' level, Service Level, and the Web/API levels. "Lock the door, but have your jewels in a 3 ton safe in the back room" A lot of the last half Shiro handles MUCH better. But I don't fell as comfortable trying to integrate openid4j/openauth4j into Shiro.

It would be REALLY nice to pick and choose the features of both, without any interference or code bloat. THAT's the best choice.

PS, Spring brings a lot of other things to the plate, also, like integration with JSF, so it has a lot of appeal.