5 Replies Latest reply on Jun 30, 2006 2:33 PM by starksm64

    Security for JBossCache?

    genman


      Perhaps this isn't really worth considering, but has there been any thought of adding some sort of security layer to the Cache? Or, something like a "view" (think chroot) of an existing cache that clients can use.

      One use case I can think of is that you have a global cache defined and you want user-defined applications to use only a specific region or have read-only access to a particular region.

      Services such as JNDI and JMX support security, and what is JBoss cache but a directory? (Which sort of brings up the idea of mounting a Cache into a JNDI tree.)

      I didn't see any discussion on the JSR-107 web site. Perhaps it's outside of the roadmap.

        • 1. Re: Security for JBossCache?
          galder.zamarreno

          Actually, I was just thinking about this yesterday. This seems like a valid use case.

          • 2. Re: Security for JBossCache?
            anil.saldhana

            If ever you decide to craft any nifty security layer for JBossCache, please check with the JBoss Security team as to what is available from JBossSX (including future enhancements) and base your work from there. :)

            What you are describing is authorizing regions for JBossCache. JBossSX Authorization framework (in the works now) should accomodate you.

            • 3. Re: Security for JBossCache?
              manik

              It is an interesting thought. Implementing it could be easy enough, using a JAAS-style provider and adding an interceptor to test the credentials of every call made.

              How would credentials be passed in though? Explicitly? On retrieving a Node? Or per call? Or something attached to the current thread?

              • 4. Re: Security for JBossCache?
                genman

                You'd need to create some sort of "connect" facility, something along the lines of what's used for JMS or the database.

                The Cache itself would have a security interceptor that would check that the principal was set, then match the roles/etc. against the permissions for modifiying or reading nodes in a particular region.

                Here's one idea:

                Cache cache = (Cache)new
                 InitialContext().lookup("java:comp/env/mycache");
                cache.connect("joe", "secret");
                cache.get("foo", "key1");
                //
                cache.logout();
                


                Alternatively, to keep the cache interface small, maybe a wrapper?
                cs = new CacheSecurity(cache);
                cs.connect("joe", "secret");
                cs.logout();
                


                The security association would be kept in a thread local. One thing that is sort of bad is that the association might leak without the logout called each time. Maybe this would be more robust:

                public interface SecureCache extends Cache {
                 public void connect(String user, String pw) throws CacheSecurityException;
                 public void logout();
                }
                SecureCache c = SecureCacheFactory.lookup("java:comp/env/mycache");
                cs.connect("joe", "secret");
                cs.logout();
                


                Each "SecureCache" would be a simple wrapper around a regular cache. This way, the assocation would be matched against the instance variable. Also, if the cache in JNDI was accessed in the normal way, it would fail.

                One fine point would be to have the allowed roles and regions set in the connect method and the interceptor would simply do the method checks.


                • 5. Re: Security for JBossCache?
                  starksm64

                  This really just should be the same authentication aspect that is applied to ejb3 to obtain the current current caller context, along with whatever authorization interceptor applies to the call. I should not need a wrapper to introduce jms/jdbc type of connection based authentication. We don't need this for ejbs, and we should not need it in general.