Java 关于角色和身份验证的ejb安全问题

如果有人能帮我回答以下问题，我将不胜感激：

@RolesAllowed和@DeclareRoles注释之间有什么区别

我开发了一个登录功能，根据数据库中的信息检查用户名和密码。但是，我想问一下如何将角色分配给经过身份验证的用户，以便与上述注释一起使用

---

也许我的答案可能不正确，也可能不完整。但可以在参考资料中找到

申报单 只能在类级别中使用 当通过isCalerInRole（roleName）引用角色时，需要更新@DeclareRoles

基本思想

• 默认情况下，业务接口的所有方法都是可访问的、记录的 在不在

• 注释放在bean类上，而不是业务接口上

• 安全注释可以应用于整个类和/或单个类 方法

• 使用的任何安全角色的名称必须通过 @申报单

@角色被允许 可以在类级别和方法级别使用，以限制访问级别

一个例子 混合类和方法级别限制 可以在类级别和方法级别同时使用安全注释。这些规则不堆叠，因此标记“submitPatch”将覆盖默认的“提交者”

编辑：

下面是的代码片段。您可以使用此模块作为登录模块。通过这种方式，您可以遵循JAAS标准

在commit中，它将调用此函数来添加主体

subject.getPrincipals().addAll(allPrincipals);

您也可以在这里查看更多详细信息

它列出了您可以选择的其他选项

@RolesAllowed和@DeclareRoles注释之间有什么区别

@RolesAllowed

注释用于指定实际允许访问业务方法的角色列表。EJB在运行时的行为会受到此注释的影响，因为EJB容器会主动验证调用方是否存在于允许的角色中。此外，可以在

TYPE

s和

METHOD

s上定义此注释，允许您定义类或方法级别上允许的角色列表。可以在单个方法级别重写类的所有方法所允许的角色列表

另一方面，

@DeclareRoles

注释仅用于声明角色列表；它相当于

ejb jar.xml

文件中的

安全角色ref

元素。EJB容器不需要了解这些角色就可以对EJB的业务方法实施访问控制检查；相反，bean提供者/开发人员可以在

isCallerRole

测试中使用这些角色来确保编程安全

EJB3.1规范说明了关于

@DeclareRoles

注释的以下内容：

17.2.5.3从Bean的 代码

Bean提供者负责使用DeclareRoles注释 或部署描述符的安全角色ref元素 声明企业bean代码中使用的所有安全角色名称。 DeclareRoles注释是在bean类上指定的，其中 用于声明可通过调用isCallerInRole进行测试的角色 从带注释类的方法中。宣布安全 角色允许Bean提供程序、应用程序汇编程序或部署程序 将代码中使用的这些安全角色名称链接到安全角色 为已组装的应用程序定义。在没有这种联系的情况下 步骤中，代码中使用的任何安全角色名称都将假定为 对应于同名的安全角色

你问题的第二部分指出：

我开发了一个登录功能，根据数据库中的信息检查用户名和密码。但是，我想问一下如何将角色分配给经过身份验证的用户，以便与上述注释一起使用

在这种情况下，需要注意的一点是，我首选的方法是不使用progammatic安全性，除非您的用例实际需要它。在大多数情况下，如果可以使用声明式安全性来实现需求，则最好使用声明式安全性，因为程序安全性要求您跟踪

isCallerRole

方法调用，如果没有这样的调用，则可能会导致安全漏洞。无论如何，在您的情况下，您都需要容器首先识别数据库中的组和主体，作为可能用于访问控制检查的角色

简单地说，EJB客户端（JavaSE应用程序、servlet或其他EJB）必须首先根据容器的安全机制对自身进行身份验证，以建立调用方的

主体。因此，声明式或程序式安全性的成功使用依赖于成功的身份验证过程。在您的情况下，您需要配置容器来识别数据库中的组和用户，并将它们转换为
Principal
对象，这些对象可用于以声明或编程方式实施访问控制。大多数容器为此支持一种或多种风格的JAAS登录模块；例如，GlassFish3.1允许使用，而JBoss6.0支持使用。因此，您需要确定您的容器是否支持这样的登录模块，并将其配置为使用您的数据库

注意，在某些情况下，容器提供的登录模块可能不足以满足您的需要。在这种情况下，您需要编写自己的登录模块（如果需要，还需要针对容器的接口）

此外，还需要将应用程序使用的角色映射到JAAS领域中的用户和组。例如
subject.getPrincipals().addAll(allPrincipals);