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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
