jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Eder <lukas.e...@gmail.com>
Subject "Secure realm" of internal APIs to prevent costly access control lookups
Date Mon, 25 Mar 2013 15:09:33 GMT

I'm currently looking into extending Jackrabbit's (not OAK's) access
control management, and I found it easy to see how this area is a
significant performance bottleneck for today's Jackrabbit Content

The biggest design and architecture problem, in my opinion, is the
need for a session with associated, hard-coded access control
behaviour. From what I understand so far, there are (possibly

- System sessions
- Admin sessions
- User sessions

In my opinion, in OAK, there should be something like a "secure
realm". Once this realm is entered, executing code should get complete
access to all of the repository through standard internal and external
API. For example, such behaviour could be achieved through setting a
ThreadLocal "monitor" in a local execution context as such:

    // Outside of the "secure realm". JCR access goes through access control
    T result = secure(new Securable<T>() {
        public T run() {
            // Inside of the "secure realm". JCR access
            // would now bypass access control

And this could be the implementation of secure():

    private static final ThreadLocal<Boolean> t = new ThreadLocal<Boolean>();

    // OAK internals could use this to check if access control is needed
    public static boolean isSecured() {
        return t.get() != null;

    public static <T> T secure(Securable<T> s) {
        // Already secured
        if (isSecured()) {
            return s.run();
        else {
            try {
                return s.run();
            finally {

Such use of ThreadLocal is smelly and potentially slow, of course.
This is just to illustrate the idea. More realistic use-cases would
probably expose a shareable system session within the "secure realm".
The important thing is that this system session would also bypass
access control.

Are there any such plans in OAK?


View raw message