Page History

...

• 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^{Image Removed}
• http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/AccessControlManager.html^{Image Removed}
• 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.

Milestone 3 Sprint 3 - progress update

• security is now executed in JCR layer

Next Steps

• superuser account is treated as "admin" type account by JCR (JR) giving it all permissions always
• MagnoliaAccessProvider is partially implemented - grants all to superuser, none to anonymous
• ModeShape team is preparing MS 2.5b2 with hooks for extending security same way as possible in JR
• only magnolia jaas chain and security realm exist in JCR configuration

Next Steps

• implement security for ModeShape
• finalize implementation of Access Provider
• refactor RepositoryAccessStrategy and WorkspaceAccessUtil - related to unclosed sessions exceptions
• test and make updates necessary for working with external users/groups
• internal JR "admin" user should be replaced with superuser only, or admin should be locked out more strongly
• test with pur or anything with custom realms
• move supportBase constants to SecurityConstants
• 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.