JCR - Security

Goal

• We want to move the ACL checks to the JCR layer

Reasoning

• better performance
• JCR repository can be exposed otherwise (the ACLs are then still taken into account)
• we want to use the JCR API without needing to wrap the objects everywhere

Resources

• http://wiki.apache.org/jackrabbit/AccessControl
• http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/AccessControlManager.html
• https://confluence.sakaiproject.org/display/KERNDOC/Jackrabbit+Permissions+Resolution

Conclusion

• we cannot use "Resource-based ACLs". We had to update all the nodes on ACL changes and the permissions are only inherited on creation.
• we will provide a custom AccessControlManager. This is very similar to our current solution, its not tied to the jackrabbit API. AccessControlManager API defined by spec is insufficient to control privileges. The control could be done at this level in JackRabbit, but only by overriding JR specific methods.
• we will provide our own privilege provider. Privilege provider is already swappable in both JR and MS as each provides Resource based provider and limited role based provider.
• JR already allows specifying custom privilege provider. MS currently supports only two of its own implementation. We will initiate request to open this to custom implementations.

Next Steps

• initiate discussion with ModeShape team to open privilege provider configuration to custom implementations
• implement custom privilege provider utilizing existing Magnolia users/groups/roles/ACLs.
  • find out best solution to reading all privilege info from repository during user authentication process and compiling privileges to make checking as fast as possible.
  • privilege provider has unsupervised access to the workspace to which session is bound, however our privileges are scattered over 3 workspaces. Therefore we need to retrieve permissions at the login time as done currently, compile them for efficient checking and keep associated with the user for the duration of the user login.
• currently we have 2 jaas chains. Since we want to use JCR to check for permissions, we should probably try to keep just one chain and authenticate on the JCR layer directly. (It is currently unclear if the only reason for 2 chains was to bypass JR authentication or if there was some other reason too ... if you know, please comment)