...
- 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.
AccessControlManagerAPI 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
Milestone 3 Sprint 3 - progress update
- security is now executed in JCR layer
superuseraccount is treated as "admin" type account by JCR (JR) giving it all permissions alwaysMagnoliaAccessProvideris 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
RepositoryAccessStrategyandWorkspaceAccessUtil- 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.
- 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)