[infinispan-dev] "Lightweight" security

Tristan Tarrant ttarrant at redhat.com
Thu Jun 12 07:58:34 EDT 2014


Hi all,

This morning I have issued a rather large PR [1] which contains a new 
way to handle security. Because of the implications, I thought it best 
to explain the rationale behind it here.

When a cache has been configured with authorization, retrieving such a 
cache returns an instance of SecureCache. SecureCache is a simple 
wrapper around a Cache which checks whether the "current user" has 
enough permissions to perform an operation.
For us the "current user" is a Subject associated with the 
AccessControlContext, which basically means Subject.doAs(subject, ...).
Occasionally, however, we have internal code which needs to do things 
with caches with "elevated privileges". As an example, the distexec code 
needs to check the cache configuration and obtain the RpcManager, 
operations which the current Subject might not have.
In my initial implementation, this was done using the 
AccessController.doPrivileged(...) method which requires the presence of 
a SecurityManager to be able to grant the privileges to trusted code.
Unfortunately a SecurityManager is a bit overkill (usability-wise and 
performance-wise) for our use-case, since its purpose is mainly to avoid 
running untrusted code (think an applet).
But the typical "authorization"-enabled Infinispan application is 
running trusted code, and it just needs a way to identify one Subject 
from another when performing cache operations.

So, I present to you the new org.infinispan.security.Security class 
which uses a much simpler approach: it identifies "privileged" code 
simply by its package name, using the caller stack in a way similar to 
what logging frameworks do. While this approach is "insecure" in the 
usual meaning of the word, since it can be easily subverted, it covers 
the common use-case in a much lighter and faster way.
Obviously using a SecurityManager, if so inclined, is still supported 
and will be used to validate privileges if present.

Tristan

[1] https://github.com/infinispan/infinispan/pull/2629


More information about the infinispan-dev mailing list