Java EE 服务器上的动态角色
我想在专用应用程序中管理用户和角色。例如，此应用程序的用户（“customerX 老板”）可以创建新角色“customerX 员工”。如果员工访问 Java EE 应用程序服务器 (GlassFish 3)，他应该获得“customerX 员工”角色。
听起来很简单，但 Java EE 不支持它，因为组在启动时映射到角色，而应用程序中的角色是静态的。
在 Java EE (6) 环境中运行时管理用户角色的最佳方法是什么？
I want to manage user and roles in a dedicated application. For example a user of this application ("customerX boss") can create a new role "customerX employee". If an employee accesses the Java EE application server (GlassFish 3) he should get the role "customerX employee".
It sounds simple, but it is not supported by Java EE, because groups are mapped to roles at start-up time and the roles within the application are static.
What is the best way to manage user roles at runtime in a Java EE (6) environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Java EE 中的声明式安全性确实不适合此类需求。安全问题可以分为两部分：
我曾经有过类似的要求。我们使用内置身份验证来设置主体，然后依赖默认的 Java EE 登录机制。但我们最终在应用程序级别手动管理授权部分。
事实上，即使是要加载并与主体关联的角色（对于 Web 来说是
isUserInRole，对于 EJB 来说是isCallerInRole）也需要在web.xml 中指定或ejb.xml无法提供足够的灵活性。然后，我们必须从 LDAP 或 ActiveDirectory 手动加载角色（根据主体）。然后我们使用 EJB3 拦截器和 Servlet 过滤器自行执行安全检查。然而，我强烈建议坚持基于角色的访问控制（RBAC），而不是实现更奇特的东西。有几个框架可以帮助处理自制的 RBAC。
我们还查看了 JSecurity 和 Acegi Security 他们看起来很有趣。
The declarative security in Java EE is indeed no suited for such requirements. The problem of security can be split in two:
I had similar requirement once. We used the built-in authentication to have the principal set and relied then on the default Java EE login mechanisms. But we ended up managing the authorization part manually at the applicative-level.
Indeed, even the roles that will be loaded and associated with the principal (
isUserInRolefor the web andisCallerInRolefor the EJB) need to be specified inweb.xmlorejb.xmlwhich doesn't provide enough flexibility. We had then to load the roles manually (according to the principal) from LDAP or ActiveDirectory. We then used EJB3 interceptors and Servlet filter to perform the security checks ourselves.I would however strongly suggest to stick to a Role-based access control (RBAC) and not implement something more fancy. There are several frameworks that can help to deal with home-made RBAC.
We also had a look at JSecurity and Acegi Security and they seemed interesting.