何时从容器管理的安全性转向 Apache Shiro、Spring Security 等替代方案?

发布于 2024-12-10 03:48:59 字数 544 浏览 0 评论 0原文

我正在尝试保护使用 JSF2.0 构建的应用程序的安全。

我很困惑人们什么时候会选择使用 Shiro、Spring Security 或 owasp 的 esapi 等安全替代方案,而放弃容器管理的安全性。看过一些 Stack Overflow 上的相关问题,我意识到过去 JSF 开发人员更喜欢基于容器的安全性。但我也被强烈推荐使用 Apache Shiro。我在安全问题方面是新手,不知道相关问题是什么?如何对付他们。因此,我正在寻找能够通过其默认设置/自行处理大多数安全问题的东西。

就我的应用程序要求而言,我有一个社交应用程序,其中具有不同角色的用户可以访问不同的页面集,并且可以根据其角色在这些页面上使用不同级别的功能。

在这种情况下,您认为我应该选择什么?

我个人确信选择 Shiro,因为它易于使用并且可以为新手处理大部分事情。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

儭儭莪哋寶赑 2024-12-17 03:48:59

我喜欢 Shiro 的一点是,它非常容易设置基于权限的安全性。 JAAS 很大程度上基于角色,具有讽刺意味的是,这种粒度对消费者 Web 应用程序比对企业应用程序更有用(正如我们从您的需求中可以注意到的那样)。

  • 应用程序服务器通常在 JAAS 之上提供一些服务,例如单点登录、内置登录模块等,因此有时当权限粒度不是必需的时,您应该选择 JAAS。

  • 上次我检查 Shiro 也不支持相互 ssl 身份验证(使用数字证书),但您可能不会使用它...

  • 如果您使用 Shiro,您的应用程序可能会在应用程序服务器/servlet 容器之间更具可移植性(哦,讽刺的是!),因为 JavaEE 安全性对于大多数人来说,配置往往是特定于供应商的重要的设置。

总而言之,根据您指定的要求:

  • 使用 AppServer(GlassFish、JBoss):JAAS(ootb authc/authz、内置登录模块)
  • 使用 Servlet 容器(Jetty/Tomcat):Shiro(更易于设置)并使用)

希望有帮助:)

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 :)

野鹿林 2024-12-17 03:48:59

除了以下内容之外,我对 Apache Shiro 一无所知,但您所引用的内容实际上是逐字来自他们的 网页,其中包含一些错误陈述,例如“[JAAS] 需要只有程序员才能更改的静态定义”和“JAAS 与虚拟机级问题的联系过于紧密”,以及 JAAS 的含义与用户和角色无关,这完全是错误的。我希望有足够的说服力来放弃容器管理的安全性。它是 Servlet 规范的一部分,因此任何容器都必须支持它;很好理解;它由 JDK 类支持,无需第三方; ...这对我有用;-)

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 ;-)

树深时见影 2024-12-17 03:48:59

我决定 SpringSecurity (SS) 将成为我们的身份验证和授权框架。主要是因为SS做了OpenID和OAuth。我必须对权限/组/用户/实体系统进行相当多的自定义。我计划在“EntityManager/Entity”级别、服务级别和 Web/API 级别进行授权。 “锁上门,但把你的珠宝放在后面房间的 3 吨重的保险箱里” 很多后半部分 Shiro 处理得更好。但我不太愿意尝试将 openid4j/openauth4j 集成到 Shiro 中。

如果能够挑选并选择两者的功能,而不会有任何干扰或代码膨胀,那真是太好了。这是最好的选择。

PS,Spring 还带来了很多其他的东西,比如与 JSF 的集成,所以它有很大的吸引力。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文