Rob wrote: > It makes sense to me to have queries evaluated using a particular Context (be > they search etc) only return objects that the currently-authenticated > e-person can 'see'. The system has not evolved in a way amenable to this, > however. Post-query filtering doesn't work because if you ask for 'the first > 10 items with titles starting with C', you may end up with only 6 visible > results. For a more general solution, either every indexing system needs to > be ACL-aware (yuck), or we should create a unified query API whose > implementation is ACL-aware, i.e. indexes relevant permissions. Lucene seems > the most likely candidate for such an API. Unfortunately things seem to be > diversifying rather than unifying in this area...
I echo Rob's sentiments regarding query filtering based on AuthZ policies being "hard," and esp. would like to emphasize that this issue needs to be clarified as a new DSpace AuthZ model/subsystem is designed. One reason is, it would probably be implemented as a further constraint on any query; it certainly would ACT like that. User specifies query; system (in principle) extends query to ensure that ineligible objects will be excluded from results; query is evaluated; the desired number of results are presented. This is important: IF you're going to have AuthZ policies, you MUST extend these to query results. The tricky bit is, if your system doesn't have a policy-based mechanism for expressing AuthZ "policies," how do you go about expressing those constraints (the ones that extend the queries, as above)? Clearly, you'd like your policy expressions to be consistent as possible with your query expressions. One way to do this might be to use an attribute (e.g. metadata) based mechanism, in which policies are based upon logical expressions over attributes of the objects. XACML does this (attribute expressions) to a basic extent, although there are limitations in it's expressiveness and generality. John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
