Vin*_*lds 21
@RolesAllowed和@DeclareRoles注释之间有什么区别？
该@RolesAllowed批注用于指定实际上是允许访问的业务方法的角色列表.EJB在运行时的行为受此注释的影响,因为EJB容器主动验证调用者是否存在于允许的角色中.此外,可以在TYPEs和METHODs 上定义此注释,从而允许您定义类或方法级别允许的角色列表.您可以在单个方法的级别覆盖类的所有方法允许的角色列表.
@DeclareRoles另一方面,注释仅用于声明角色列表; 它相当于文件中的security-role-ref元素ejb-jar.xml.EJB容器不需要知道这些角色来强制对EJB的业务方法进行访问控制检查; 相反,bean提供者/开发者可以在isCallerInRole测试中使用这些角色来确保编程安全性.
EJB 3.1规范声明了以下关于@DeclareRoles注释的内容:
17.2.5.3 Bean的代码引用的安全角色声明
Bean Provider负责使用DeclareRoles批注或部署描述符的security-role-ref元素来声明企业bean代码中使用的所有安全角色名称.DeclareRoles注释是在bean类上指定的,它用于声明可以通过在带注释的类的方法中调用isCallerInRole来测试的角色.声明安全角色允许Bean Provider,Application Assembler或Deployer将代码中使用的这些安全角色名称链接到为已组装的应用程序定义的安全角色.在没有此链接步骤的情况下,将假定代码中使用的任何安全角色名称对应于同名的安全角色.
问题的第二部分说明:
我开发了一个登录功能,根据数据库中的信息检查用户名和密码.但是,我想问一下如何为经过身份验证的用户分配一个角色,以便与上述注释一起使用.
在这种情况下,需要注意的一点是,我的首选方法是不使用progammatic安全性,除非您的用例实际需要它.在大多数事件中,如果可以通过声明性安全性来实现要求,则最好使用它,因为编程安全性要求您跟踪isCallerInRole方法调用,并且缺少此类调用可能会导致安全漏洞.无论哪种方式,在您的情况下,您将需要您的容器首先识别数据库中的组和主体,作为可能用于访问控制检查的角色.
简单来说,EJB客户端(Java SE应用程序,或servlet或其他EJB)必须首先根据容器的安全机制对自身进行身份验证,以建立调用者Principal.因此,成功使用Declarative或Progammatic安全性依赖于成功的身份验证过程.在您的情况下,您需要配置容器以识别数据库中的组和用户,并将其转换为Principal可用于以声明或编程方式强制实施访问控制的对象.为此,大多数容器支持一种或多种JAAS登录模块; 例如,Glassfish 3.1允许使用JDBCRealm,而JBoss 6.0使用DatabaseServerLoginModule支持此功能.因此,您需要确定容器是否支持此类登录模块,并将其配置为使用您的数据库.
请注意,在某些情况下,提供登录模块的容器可能不足以满足您的需求.在这种情况下,您需要编写自己的登录模块(如果需要,还需要编写容器的接口).
此外,您还需要将应用程序使用的角色映射到JAAS领域中的用户和组.例如,如果您的数据库由JAAS领域使用:
U1,U2,U3,U4和U5,和G1,G2和G3含U1,U2,U3分别R1,R2并R3(通过定义的@RolesAllowed注释)来访问它的方法,那么你需要将角色映射到JAAS领域中的主体(用户和组).即使在角色名称与主体名称相同的情况下,也必须完成映射; Glassfish通过支持将类似命名的主体(用户或组)直接映射到角色的默认主体到角色映射来简化这一过程.此外,映射过程是特定于容器的,正如您所猜测的那样,此映射在容器特定的部署描述符中执行,而不是在EJB部署描述符(ejb-jar.xml)中执行.
要完成答案,您需要为每个创建的用户分配一个角色.为简单起见,您可以创建一个所有用户可能属于的单个用户组.当用户针对JAAS领域对自己进行身份验证时,Principal对象将包含此组.然后,您的JAAS领域中的组可以映射到EJB角色,并且可以在@RolesAllowed批注中指定角色名称.数据库中不在此组中的任何用户都将无法通过EJB容器访问带注释的方法.
| 归档时间： |
|
| 查看次数： |
7543 次 |
| 最近记录： |