Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Scout » [NEON] Fine grained access control((I think I figured it out))
icon14.gif  [NEON] Fine grained access control [message #1750706] Mon, 26 December 2016 21:18 Go to next message
Marco Dörfliger is currently offline Marco DörfligerFriend
Messages: 46
Registered: January 2015
Member
I've recently been implementing a permission system in Neon. The BasicHierarchyPermission API has changed a bit since the Mars release, the documentation still uses the old API, and the javadoc, although helpful, is a bit thin I think. I'm posting my solution here in the hopes that a) someone closer to the 'source' can tell me if I understood it correctly, and b) to save others time in future, assuming point a) of course. Smile

To cut a long story short, here's one permission implementation:
public class UpdateProjectPermission extends BasicHierarchyPermission {

    private static final long serialVersionUID = 1L;
    public static final int LEVEL_PROJECT = 10;
    private long projectId;

    public UpdateProjectPermission() {
	super(UpdateProjectPermission.class.getSimpleName() + ".*", LEVEL_PROJECT);
    }

    public UpdateProjectPermission(long projectId) {
	super(UpdateProjectPermission.class.getSimpleName() + "." + projectId, LEVEL_UNDEFINED);
	this.projectId = projectId;
    }

    public long getProjectId() {
	return projectId;
    }

    @Override
    protected int execCalculateLevel(BasicHierarchyPermission other) {
	int result = LEVEL_ALL;
	if (other instanceof UpdateProjectPermission) {
	    long projectNr = ((UpdateProjectPermission) other).getProjectId();
	    Participation level = BEANS.get(IProjectService.class).getParticipationLevel(projectNr);
	    if (level != null && level.ordinal() >= Participation.MEMBER.ordinal()) {
		result = LEVEL_PROJECT;
	    }
	}
	return result;
    }
}

With this implementation, the following calls can be made:

  • ACCESS.getLevel(new UpdateProjectPermission()) will indicate which level of access the user has with regards to all projects. If the granted permissions level is LEVEL_PROJECT, it means s/he can update projects to which he or she is a MEMBER of. And of course the defaults apply: LEVEL_ALL means all projects, and LEVEL_NONE means none.
  • ACCESS.check(new UpdateProjectPermission(3)) will indicate whether the current user may update the project with id 3. It will trigger execCalculateLevel() which, after consulting the back-end service, will determine the required level the user needs to have on the global permission for access to be granted. If execCalculateLevel() returns LEVEL_PROJECT, and the user was assigned an UpdateProjectPermission level of at least LEVEL_PROJECT, the ACCESS.check() call will return true.
Notes:

  • Participation is an enum with values NONE,VIEWER,MEMBER and MANAGER.
  • I found that it was absolutely necessary to append ".*" to the permission name in the zero-argument constructor. Without it, project-specific permissions (i.e. those instantiated using the single-argument constructor) would not be considered as possible delegates during the background Permission.implies() operation, resulting in ACCESS.check() returning false without even consulting execCalculateLevel() on the permission.
  • As documented, it is necessary to set the default permission level to LEVEL_UNKNOWN in the single-argument constructor.
  • Only global (zero-arg) permissions are loaded on startup during ServerAccessControlService.execLoadPermissions(). The single-argument constructor is solely for checking against individual project IDs from within the application itself.
Does this look correct to you? Comments appreciated.

[Updated on: Tue, 27 December 2016 10:50]

Report message to a moderator

Re: [NEON] Fine grained access control [message #1751739 is a reply to message #1750706] Fri, 13 January 2017 10:33 Go to previous messageGo to next message
Ralph Steiner is currently offline Ralph SteinerFriend
Messages: 3
Registered: April 2010
Junior Member
The implementation of BasicHierarchyPermission has been adapted for the new ICache. I've sheduled task that the documentation gets an update.

Your implementation looks fine to me and should work. Also all observations you have made are correct.
Let me add one additional note:
You do not need to use extend permission names if you implement hashCode and equals.

public class UpdateProjectPermission extends BasicHierarchyPermission {
  private static final long serialVersionUID = 1L;

  private final long projectId;

  /**
   * Constructor used to check access for projectId
   */
  public UpdateProjectPermission(long projectId) {
    super(UpdateProjectPermission.class.getSimpleName());
    this.projectId = projectId;
  }

  /**
   * Constructor used in {@link AbstractAccessControlService#execLoadPermissions}.
   */
  public UpdateProjectPermission(int level) {
    super(UpdateProjectPermission.class.getSimpleName(), level);
    this.projectId = 0;
  }

  public long getProjectId() {
    return projectId;
  }
  
  @Override
  protected int execCalculateLevel(BasicHierarchyPermission other) {
    ...
  }

  @Override
  public int hashCode() {
    final int prime = 31;
    int result = super.hashCode();
    result = prime * result + (int) (projectId ^ (projectId >>> 32));
    return result;
  }

  @Override
  public boolean equals(Object obj) {
    if (this == obj) {
      return true;
    }
    if (!super.equals(obj)) {
      return false;
    }
    if (getClass() != obj.getClass()) {
      return false;
    }
    UpdateProjectPermission other = (UpdateProjectPermission) obj;
    if (projectId != other.projectId) {
      return false;
    }
    return true;
  }
}
Re: [NEON] Fine grained access control [message #1751824 is a reply to message #1751739] Sun, 15 January 2017 10:46 Go to previous message
Marco Dörfliger is currently offline Marco DörfligerFriend
Messages: 46
Registered: January 2015
Member
Great, thanks for the perspective. I hadn't considered the possibility of implementing the equals() method. I think it's useful to see how people are implementing Scout projects.
Previous Topic:Download file
Next Topic:[neon] Can the JobAPI replace the Eclipse.JobGroup functionality
Goto Forum:
  


Current Time: Tue Apr 23 16:58:10 GMT 2024

Powered by FUDForum. Page generated in 0.03113 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top