Hi,
I am trying to port an Authorization scheme from Jackrabbit 1.4 to
Sling (and JR 1.5), but I want to do it in a way that is compatible
with both Sling and JSR-283.
Currently:
ACL's are stored on nodes as properties.
Each ACL on each node contains multiple Access controls statements,
(ACS) (like ACE's in 283 I think).
The ACS is made up of multiple parts; a permission selector, a target
subject, a granted/denied flag, an inheritance flag and a priority.
The target subject points to one of; a specific user, group
+permission, node owner, any authenticated user, or occasionally a
plugin.
When the 170 Access Manager is called, a ACL for the item in question
is constructed by working back up the node hierachy and collecting
together all inheritable ACE, and then ordering that list by distance
from the item and the priority.
From this ordered list, a sub set is selected by evaluating the
permissions selector against the permission being requested (the
permission selector can have wild cards).
The ordered set is then evaluated in sequence against the users state.
(users state is everything known about the user, some of which may be
lazy loaded on request or be context and time sensitive).
If a granted is found, the permission is granted. If a denied is
found, the permission is denied. If nothing is found the permission is
assumed to have been denied.
All of the above works in JR 1.4 with a 170 AccessManager and nearly
all the resolutions are in memory as the ACL's can be cached and the
users state is cached with a TTL, so appears to have minimal impact
under load when compared to a 'grant everything' AccessManager
implementation.
So the question,
I would like to port this to use as much of the default infrastructure
available in Sling/JR15, and conform to 283. Where would I get an
insight into the Roadmap of JR15, Sling in this area, and how does it
relate to the 283 Spec, which from a brief scan contains many of the
concepts implemented above? (I will now go an give the spec a much
longer scan :) )
Ian
