Java EE安全模型是否支持ACL? [英] Does Java EE security model support ACL?

查看:100
本文介绍了Java EE安全模型是否支持ACL?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在Glassfish v3.0.1中使用了Java EE 6,并且我想知道Java EE安全模型是否支持ACL,如果可以的话,它是如何获得的?



EDITED

我通过glassfish v3实现了使用jdbc领域的安全性,运行时的领域将查看数据库中的USER USER以检查身份验证,方法是查看密码字段和授权,方法是查看角色字段。角色字段只包含2个 ADMINISTRATOR DESIGNER 。所以它是用户和角色之间的一对一映射。在托管bean级别,我实现了这个

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


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

public String getLoginUserName()
{
Principal loginUser = getLoggedInUser();
if(loginUser!= null)
{
return loginUser.getName();
}
返回无;
}

通过调用 isUserInRole ,我可以确定用户是否是 admin ,然后JSF将渲染内容。但是,这还不够细致(真正的快速背景信息:有多个项目,一个项目包含多个图纸)。因为如果你是 DESIGNER ,你可以看到所有项目的所有图纸(如果我只想要 tom 在项目 A 上工作,而 peter 可用于项目 B Cindy 可以监督两个项目 A B )。我希望在运行时创建用户时,我可以专门设置他/她看到的项目。有没有办法做到这一点? 注意:不止有两个项目,上面的示例仅供演示

解决方案

Java EE安全模型验证可能拥有一个或多个'角色'的'Principal'。 b
$ b

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

哪个'Principals'或'Roles'拥有'Permissions'或'Capabilities'。

换句话说,是的,它支持ACL,并且它像你想要的一样细致它应该是,但你必须习惯术语。



在Vineet的答案中是为每个项目ID创建'角色'的绝佳建议。由于无论如何都必须将人员分配到项目中,因此在当时将人员添加到这些组是很简单的。或者,定时脚本可以根据角色更新组成员资格。后一种方法可能更可取,因为如果这些决定在一个地方而不是分散在整个管理代码中,则更容易验证安全性。另外,您也可以使用粗粒度的角色,例如设计者并利用数据库(或程序逻辑)来限制用户登录的视图

  SELECT p。* FROM项目p,赋值WHERE p.id = a.projectId AND a.finishdate<现在(); 

  @Stateless类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和s的示例eam:

 <! -  richfaces  - > 
< rich:panel header =管理控制台rendered =#{rich:isUserInRole('admin')}>
非常敏感的信息
< / rich:panel>

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

这是一篇文章,解释如何将其添加到ADF中


I used Java EE 6 with Glassfish v3.0.1, and I wonder if Java EE security model support ACL, and if so how fine-grained is it get?

EDITED
I implement Security using jdbc realm via glassfish v3, that the realm at runtime look into table USER inside the database to check for authentication, by looking at the password field and authorization by looking at the role field. The roles field only contain 2 either ADMINISTRATOR or DESIGNER. So it is a One-to-one map between user and role. At the managed bean level, I implemented this

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";
} 

by calling isUserInRole, I can determine if the user is admin or not, then the JSF will render the content appropriately. However, that is not fine-grained enough (real quick background info: There are multiple projects, a project contains multiple drawings). Because if u are a DESIGNER, you can see all the drawings from all the projects (what if I only want tom to work on project A, while peter will work on project B, Cindy can supervised over the two project A and B). I want that, at runtime, when I create the user, I can specifically set what project can he/she see. Is there a way to accomplish this? NOTE: There are more than just two projects, the above example is just for demonstration.

解决方案

The Java EE security model authenticates a 'Principal' which may one have or more 'Roles'.

In the other dimension you have services and resources which need configurable 'Permissions' or 'Capabilities'.

In the configuration you determine which 'Principals' or 'Roles' have which 'Permissions' or 'Capabilities'.

In other words, yes it supports ACL and it is as fine grained as you want it to be, but you'll have to get used to the terminology.

In the answer of Vineet is the excellent suggestion to create 'roles' per project id. Since people must be assigned to projects anyhow, it is straightforward to to add the people to these groups at that time. Alternatively a timed script can update the group memberships based on the roles. The latter approach can be preferable, because it is easier to verify security if these decisions are in one place instead of scattered all over the administration code.

Alternatively you can use "coarse-grained" roles e.g. designer and make use of the database (or program logic) to restrict the views for the user logged in

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

or

@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
        }
    }

}

Note that the coarse grained access control has here been done with an annotation instead of code. This can move a lot of hard to test boilerplate out of the code and save a lot of time.

There are similar features to render webpages where you can render parts of the screen based on the current user using a tag typically.

Also because security is such a wide reaching concern, I think it is better to use the provided features to get at the context than to pass a battery of boolean flags like isAdmin around as this quickly becomes very messy. It increases coupling and it is another thing making the classes harder to unit-test.

In many JSF implementations there are tags which can help rendering optional things. Here is are examples for richfaces and 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 explaining how to add it to ADF

这篇关于Java EE安全模型是否支持ACL?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆