This post originated from an RSS feed registered with Java Buzz by Brian McCallister. Original Post: ObjectFilter: AOP Rule Based Object Access Feed Title: Waste of Time Feed URL: http://kasparov.skife.org/blog/index.rss Feed Description: A simple waste of time and weblog experiment Latest Java Buzz Posts Latest Java Buzz Posts by Brian McCallister Latest Posts From Waste of Time

I took a couple hours this evening to port my object-access security aspects from YAIL to AspectJ this evening -- and like the results so much I am releasing them.

ObjectFilter is designed to raise the bar on access security. I cannot count the different ways I have gone about preventing information leakage by checking primary keys etc. Its awful. AOP makes it much easier. Look carefully at the two test cases here:

    public void testBlockReference()
    {
        Filter filter = Filter.instance();
        filter.setActor(new Object());
        filter.addRules(Teacher.class, new Rules()
        {
            public boolean allow(Object actor, Object instance)
            {
                return false;
            }
        });

        Teacher mr_brown = new Teacher("Mr. Brown");
        ClassRoom english = new ClassRoom(mr_brown);
        assertNull(english.getTeacher());
    }

    public void testAllowReference()
    {
        Filter filter = Filter.instance();
        filter.setActor(new Object());
        filter.addRules(Teacher.class, new Rules()
        {
            public boolean allow(Object actor, Object instance)
            {
                return true;
            }
        });

        Teacher mr_smith = new Teacher("Mr. Smith");
        ClassRoom english = new ClassRoom(mr_smith);
        assertEquals(mr_smith, english.getTeacher());
    }

The one nulls out the reference, the other allows it. ObjectFilter works by applying rules (abstracted out to the Rules interface) governing access to particular types. The rules reference a thread local actor (ObjectFilter presumes you can say only one user is on a thread) for testing access.

In addition to nulling out properties, it has limited abilities at prsent to filter collections (only allow client code to see what it is allowed to see).

The rules used in the tests above are pretty simplistic. I've done fancier in in the YAIL stuff, and in a proprietary library, but the best will probably grow out of this as, well, it is open source and there are smarter people than me around. I expect writing rules as Groovy closures might work well ;-) Right now rules are set on a type, and the logical AND of all the Rules instances that apply to an instance are used (check out this test for an example, near the end of it with StudentTeacher

The source tarball is available under an ASL 2.0 license. Have fun. The AspectJ jars are not included in the tarball, need to save some of my bandwidth. Just grab AspectJ 1.1 from eclipse.org and drop aspectjrt.jar and aspectjtools.jar in the lib

Feedback is much appreciated -- particularly in how to more elegantly handle collections and define the pointcuts for the two aspects (look for the aspects in the src/test tree to see what I mean). I am thinking about deriving them via an xdoclet/qdox style system and generating the sub-aspect at compile time. Dunno, need to think about it.