Earlier I had raised the idea that JCR might exist behind RMI potentially in a remote JVM. Once thing I hadn’t considered was the security model. In past implementations of Jackrabbit as a Service in Sakai it was tightly bound and embedded. There is a security manager that uses JAAS to connect to the Sakai Security services (AuthZGroups) and answer role/context based security questions.

If a JCR was to be accessed over RMI, then this model would need to stand, as the JCR would still need to answer fine grained security questions. In a remote environment, we loose some of the efficiencies when answering the security questions directly, however the SercurityManager abstraction in Jackrabbit/JCR would enable us to plug in an implementation suitable for connecting to Sakai. Options include taking a stub of the SakaiFramework with enough support to use the AuthZGroup service through to basing something on Guanxi and an IDP. Bear in mind however that the number of security questions that are answered in the JCR is high and the scope of those questions extremely wide and so direct integration with the SakaiFramework might be the best approach.

The other ugly head that a remote JCR raises is just how the user is identified. We no longer have the request thread from which to gather the current user. We need to provide a securely hashed token that identifies the user logged into Sakai. Naturally this would be part of the JCR session so that when the JAAS implementation was asked to answer a security question it would consult this token to determine which Sakai user was associated with the request.

Why am I even thinking about this…..

Scalability. Just as has recently been done with search, where a search cluster can exist within a Sakai cluster, as a group of compute nodes dedicated to search operations which deliver search results over a REST based web service. A JCR cluster will remove processing load and memory footprint from the front end request based services. There is limited scope at the moment to make the link asynchronous, but it opens the way in the future. JCR-RMI also makes opens the door to make other JCR implementations pluggable as a back end cluster or even to integrate with the future institutional JCR.