Java EE 安全模型是否支持 ACL？

Question

我使用了带有 Glassfish v3.0.1 的 Java EE 6，我想知道 Java EE 安全模型是否支持 ACL，如果支持，它的粒度有多细？

已编辑
我通过 glassfish v3 使用 jdbc 领域实现安全性，该领域在运行时通过查看 password 字段和授权通过查看 role 字段来查看数据库中的表 USER 以检查身份验证。角色字段仅包含 2 个 ADMINISTRATOR 或 DESIGNER。所以它是用户和角色之间的一对一映射。在托管 bean 级别，我实现了这个

private Principal getLoggedInUser()
{
    HttpServletRequest request =
            (HttpServletRequest) FacesContext.getCurrentInstance().
                getExternalContext().getRequest();
    if(request.isUserInRole("ADMINISTRATORS")){
        admin = true;
    }else{
        admin = false;
    }
    return request.getUserPrincipal();
}

public boolean isUserNotLogin()
{
    Principal loginUser = getLoggedInUser();
    if (loginUser == null)
    {
        return true;
    }
    return false;
}

public String getLoginUserName()
{
    Principal loginUser = getLoggedInUser();
    if (loginUser != null)
    {
        return loginUser.getName();
    }
    return "None";
} 

通过调用isUserInRole，我可以确定用户是否为admin，然后JSF将适当地render内容。但是，这还不够细粒度（真正的快速背景信息：有多个项目，一个项目包含多个图纸）。因为如果你是DESIGNER，你可以看到所有项目的所有图纸（如果我只希望tom 处理项目A，而peter 将处理项目B，@987654334 @可以监督A和B这两个项目。我希望在运行时，当我创建用户时，我可以专门设置他/她可以看到什么项目。有没有办法做到这一点？ 注意：不止两个项目，以上示例仅用于演示。

Answer 1

Java EE 安全模型对可能具有一个或多个“角色”的“主体”进行身份验证。

在另一个维度中，您拥有需要可配置的“权限”或“功能”的服务和资源。

在配置中，您可以确定哪些“主体”或“角色”具有哪些“权限”或“能力”。

换句话说，是的，它支持 ACL，并且可以根据您的需要进行细粒度，但是您必须习惯该术语。

Vineet 的回答是为每个项目 ID 创建“角色”的绝佳建议。由于无论如何都必须将人员分配到项目中，因此可以直接将人员添加到这些组中。或者，定时脚本可以根据角色更新组成员资格。后一种方法可能更可取，因为如果这些决策在一个地方而不是分散在管理代码中，则更容易验证安全性。

或者，您可以使用“粗粒度”角色，例如设计师并利用数据库（或程序逻辑）来限制登录用户的视图

SELECT p.* FROM projects p, assignments a WHERE p.id = a.projectId AND a.finishdate < NOW();

或

@Stateless class SomeThing {

    @Resource SessionContext ctx;

    @RolesAllowed("DESIGNER")
    public void doSomething(Project project) {
        String userName = ctx.getCallerPrincipal.getName();

        if (project.getTeamMembers().contains(userName) {
            // do stuff
        }
    }

}

请注意，这里的粗粒度访问控制是通过注释而不是代码完成的。这可以将大量难以测试的样板代码移出代码并节省大量时间。

有类似的功能可以渲染网页，您可以根据当前用户通常使用标签来渲染部分屏幕。

另外，由于安全性是一个广泛涉及的问题，我认为使用提供的功能来获取上下文比传递像 isAdmin 这样的一系列布尔标志更好，因为这很快就会变成很乱。它增加了耦合，并且使类更难进行单元测试是另一回事。

在许多 JSF 实现中，有一些标签可以帮助呈现可选的东西。以下是 Richfaces 和 seam 的示例：

<!-- richfaces -->
<rich:panel header="Admin panel" rendered="#{rich:isUserInRole('admin')}">
  Very sensitive information
</rich:panel>

<!-- seam -->
<h:commandButton value="edit" rendered="#{isUserInRole['admin']}"/>.

Here is an article 解释如何将其添加到 ADF

Answer 2

Java EE 安全模型实现了 RBAC（基于角色的访问控制）。对于 Java EE 程序员来说，这实际上意味着可以将访问资源的权限授予用户。资源可能包括文件、数据库甚至代码。因此，不仅可以限制对数据库中文件和表等对象的访问，还可以限制对可执行代码的访问。

现在，可以将权限分组到最终链接到用户/主题的角色中。简而言之，这就是 Java EE 安全模型。

根据您的问题描述，您似乎希望将两个不同的项目区分为两个不同的资源，因此有两个单独的权限对象或两个单独的角色来解释相同的问题。鉴于您已经拥有管理员、设计师等角色（更恰当地称为用户组），这在 Java EE 中无法轻松实现。原因是您根据资源的附加属性 - 项目 ID 来区分角色中用户对资源的访问。这在技术上属于称为 ABAC（基于属性的访问控制）的领域。

在 Java EE 中实现 ABAC 的一种方法是在角色名称中携带授予角色的属性/属性。所以代替下面的代码：

if(request.isUserInRole("DESIGNERS")){
    access = true;
}else{
    access = false;
}

您应该执行以下操作。请注意用作分隔符的“:”字符，以将角色名称与随附的属性区分开来。

if(request.isUserInRole("DESIGNERS"+":"+projectId)){
    access = true;
}else{
    access = false;
}

当然，您的登录模块的某些部分应该被修改（在配置中或在代码中）以返回包含项目 ID 的角色，而不是简单的角色名称。请注意，所有这些建议的更改都需要针对问题进行全面审查 - 例如，应该禁止分隔符作为角色名称的一部分，否则很有可能执行权限提升攻击。

如果证明上述实现很少，您可以查看像 Shibboleth 这样提供 ABAC 支持的系统，尽管我从未见过它在 Java EE 应用程序中使用。