JavaEE安全模型支持ACL吗?

JavaEE安全模型支持ACL吗?,java,security,jakarta-ee,glassfish,acl,Java,Security,Jakarta Ee,Glassfish,Acl,我在Glassfish v3.0.1中使用了JavaEE6,我想知道JavaEE安全模型是否支持ACL,如果支持ACL,它的细粒度如何 已编辑 我通过glassfish v3使用jdbc领域实现安全性,该领域在运行时通过查看密码字段检查数据库中的表用户以检查身份验证,并通过查看角色字段进行授权。角色字段仅包含2个管理员或设计师。因此,它是用户和角色之间的一对一映射。在托管bean级别,我实现了这个 private Principal getLoggedInUser() { HttpSer

我在Glassfish v3.0.1中使用了JavaEE6,我想知道JavaEE安全模型是否支持ACL,如果支持ACL,它的细粒度如何

已编辑
我通过glassfish v3使用jdbc领域实现安全性,该领域在运行时通过查看
密码
字段检查数据库中的表用户以检查身份验证,并通过查看
角色
字段进行授权。角色字段仅包含2个
管理员
设计师
。因此,它是用户和角色之间的一对一映射。在托管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将
适当地呈现内容。但是,这还不够精细(真正的快速背景信息:有多个项目,一个项目包含多个图形)。因为如果你是
设计师
,你可以看到所有项目的所有图纸(如果我只想
汤姆
从事项目
a
,而
彼得
将从事项目
B
辛迪
可以监督两个项目
a
B
)。我希望在运行时,当我创建用户时,我可以专门设置他/她可以看到的项目。有没有办法做到这一点注意:不止有两个项目,上面的示例仅用于演示

JavaEE安全模型对“主体”进行身份验证,该主体可能具有一个或多个“角色”

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

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

换句话说,是的,它支持ACL,并且它的粒度与您希望的一样细,但是您必须习惯这个术语

Vineet的回答中有一个很好的建议,即为每个项目id创建“角色”。因为无论如何都必须为项目分配人员,所以在那个时候将人员添加到这些组中是很简单的。或者,定时脚本可以根据角色更新组成员身份。后一种方法可能更可取,因为如果这些决策集中在一个地方而不是分散在整个管理代码中,则更容易验证安全性

或者,您可以使用“粗粒度”角色,例如设计器,并利用数据库(或程序逻辑)限制登录用户的视图

SELECT p.* FROM projects p, assignments a WHERE p.id = a.projectId AND a.finishdate < NOW();
注意,粗粒度访问控制在这里是通过注释而不是代码完成的。这可以将大量难以测试的样板文件移出代码,并节省大量时间

呈现网页也有类似的功能,您可以基于当前用户使用标签呈现部分屏幕

另外,由于安全性是一个影响广泛的问题,我认为使用提供的功能来获取上下文比传递一组布尔标志(如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']}"/>.

非常敏感的信息
.

解释如何将其添加到ADF

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

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

从对问题的描述来看,您似乎希望将两个不同的项目区分为两个不同的资源,因此需要使用两个单独的权限对象或两个单独的角色来解释相同的问题。鉴于您已经拥有管理员、设计师等角色(更恰当地称为用户组),这在JavaEE中很难实现。原因是您根据资源的附加属性(项目ID)来区分角色中的用户对资源的访问。从技术上讲,这属于ABAC(基于属性的访问控制)领域

在JavaEE中实现ABAC的一种方法是在角色名称中携带授予角色的属性。因此,不使用以下代码:

if(request.isUserInRole("DESIGNERS")){
    access = true;
}else{
    access = false;
}
你应该做如下的事情。请注意“:”字符用作分隔符,用于区分角色名称和附带属性

if(request.isUserInRole("DESIGNERS"+":"+projectId)){
    access = true;
}else{
    access = false;
}
当然,有一部分应该修改登录模块(在配置或代码中),以返回包含项目ID的角色,而不是简单的角色名称。请注意,所有这些建议的更改都需要进行全面的问题审查-例如,应该禁止分隔符字符作为角色名称的一部分,否则很可能会执行权限提升攻击


如果上面的实现被证明是少数几个,那么您可以看看为ABAC提供支持的系统,尽管我从未见过它在Java EE应用程序中使用。

为了安全起见,我使用jdbc领域编写了一些代码,但它只利用了
主体
,我不知道如何使用
权限
功能
,你认为我可以发布一些代码,并征求你的专家意见吗?如果不是从我这里,那么从这里更有知识的人那里,这总是有帮助的。我只是
if(request.isUserInRole("DESIGNERS"+":"+projectId)){
    access = true;
}else{
    access = false;
}