ACL Security In Seam, Part 1

Seam has always been about solving the common issues faced by web application developers.  By providing a selection of "Best Practice" solutions to various development challenges in a unified component model, the developer is free to work on the business logic of their application without having to worry as much about the concerns that should be rightly addressed by the framework.  Seam makes it very easy to do things such as generate PDF documents, generate and send e-mails, and internationalise your application.  It also integrates with third party projects such as jBPM and Drools to provide support for long running business processes and business rules.  Support for CAPTCHA, and a wiki-style markup language are also there, as well as a number of ways of doing AJAX.

One of the most important areas of enterprise application development though is security.  Seam has long provided a robust Security API allowing the components and views that a typical application consists of to be secured via user and role security, or rule-based security permissions.  Recently though (as of version 2.1.0.GA) Seam has overhauled its security engine to provide a number of new features offering even more ways to secure your sensitive data.  This article will look at one of these new features, persistent permissions to see how ACL, or "instance" based security can be used to secure your application at the object level.

To get started, let's examine the differences between rule-based and ACL-based security.  Rule-based security is great for applying blanket permissions to a particular class of object.  For example, let's take a look at the following security rule from one of the Seam examples:

  rule DeleteImage
    no-loop
    activation-group "permissions"
  when
    acct: MemberAccount()
    image: MemberImage(mbr : member -> (mbr.memberId.equals(acct.member.memberId)))
    check: PermissionCheck(target == image, action == "delete", granted == false)
  then
    check.grant();
  end

The conditional part of this rule (which allows users to delete images that they've previously uploaded) essentially says, "if you're the owner of this image, then you're allowed to delete it".  In this example, the security permission applies to all images and is dependent on the fact that there is a relational link between the image and its owner.  It is through this relationship that the security rule can determine that the current user is the owner of the image, and in turn grant permission to execute the action.  However, what if there was no relationship between the target of the permission check and the user (who we'll refer to as the principal from here on)?  This is where ACL security comes in.

An ACL (Access Control List) is a list of explicit permissions assigned to a particular object.  Each entry in the list contains a recipient (the principal who is granted the permission) and an action.  If you've ever used a *nix based operating system then you should already be familiar with a particular type of ACL - the file system contains a table of read, write and execute permissions for each file (yes, Windows has similar file security but it's not as obvious).  ACL-based security in Seam works much the same way, except that it is used to secure object instances instead of files.  In a typical application these object instances will generally be entities, however we'll soon see that it is possible to secure any type of object.