2016-05-23 101 views
0

迄今为止,我所见过的所有Java EE授权技术都只针对视图层 - 主要基于JSF。您基本上限制对某些URL模式或JSF组件的访问。基于Java EE的基于服务的安全

但是,我宁愿在服务上有我的安全层。我的层看起来像这样:

  • 视图(XHTML + JSF支持bean/RESTful Web服务)
  • 服务
  • 实体和业务逻辑
  • 的DAO

由于服务是我业务逻辑的代理,并且不包含任何逻辑,我想用它们来访问控制。这样我就不需要单独为每个视图技术实现安全性,也不需要注意URL模式(这些模式很难维护)。

我的首选解决方案是对服务上的类或方法的注释。如果一些视图代码试图在未经许可的情况下访问它们,它会得到一个异常(该异常被处理并应转发到登录表单)。

有什么这样的我可以使用?

回答

4

我的首选解决方案是对服务上的类或方法的注释。如果一些视图代码试图在未经许可的情况下访问它们,它会得到一个异常(该异常被处理并应转发到登录表单)。

有什么这样的我可以使用?

是的。你已经熟悉的是所谓的“应用程序级”安全性,这确实很常见。但是Java EE早已提供了内置的声明机制作为替代或辅助;这些可以在Web应用程序级别或组件级别上运行。这些细节在这里描述的太广泛了,但Java EE教程有三章介绍它们。你可能会想从the overview开始。

在一个非常高的水平,

  • 声明安全要求历来被部署描述符中表示。细节因要保护的组件或应用程序的类型而异。

  • 由于至少Java EE 6,一些安全声明也可以通过组件源中的注释进行。

  • 用户认证和授权的主要内置机制适当地为Java Authentication and Authorization Services(JAAS)。这实际上是一种Java SE技术,因此您也可以将其用于常规应用程序。如果您曾经使用Solaris的/ Linux的可插入验证模块(PAM)子系统,那么JAAS会对概念感到熟悉。

  • 一些Java EE容器和一些应用程序框架提供了它们自己的安全机制;如果你的情况允许你考虑这样的事情,那么值得看看。

+0

''用户认证和授权的主要内置机制是[J](JAAS).' 否;认证和授权由单个规范的安全模型提供,其中主要使用的(Servlet,EJB)既不是“构建”在顶层,也不是强制甚至不建议其实现依赖于JAAS。如果他们这样做,这是一个实现细节,Java EE应用程序开发人员不需要关心。如果OP需要额外的功能,则可以使用Java EE特定的标准SPI(JASPIC,JACC)。 – Uux