An Investigation into Filtering of Search Results by Access Constraints Gert Schmeltz Pedersen and Christian Tønsberg Technical Information Technical University of Denmark funded by the DEFF Fedora project Investigation triggered by discussion on fedora-commons-developers list in January 2008

Overview ➲ The Problem is... ➲ Analysis... The ideal solution is... What can you do with XACML policies? A cost model for alternative solutions to filtering of search results... What are decisive characteristics of repositories for the choice of solution? ➲ The Conclusion is...

The Problem is... ➲ Search results contain hits that the user does not have the access rights to see This has become a problem for repositories that want fine-grained control over access rights and want to use XACML policies with Fedora e.g. eSciDoc, RepoMMan /REMAP XACML = OASIS eXtensible Access Control Markup Language

Analysis... ➲ The ideal solution ➲ What can you do with XACML policies? ➲ What are the costs of various solutions to filtering of search results? ➲ What are the characteristics of repositories that are decisive for the choice of solution?

The Ideal Solution... ➲ The ideal solution includes: Choice between 1.all search result hits 2.only hits accessible by the user 1.with “read” filtering 2.( with “edit” filtering (subset of 2.1) )‏ Filtering mechanism must correspond to XACML access control mechanism Hits in “read” filtering must be readable by user ( Hits in “edit” filtering must be editable by user )‏ Objects readable by user must not be filtered out of 2.1 ( Objects editable by user must not be filtered out of 2.2 )‏ Normal paging of hits for the Choice Show number of hits for the Choice Supported for large number of users / (“virtual”) user groups Acceptable performance Search result without filtering 2Qwe rty uio pas 4Qwe rty uio pas 5Qwe rty uio pas Abstract example of Foxml objects 1Qwe rty uio pas 2Qwe rty uio pas 3Qwe rty uio pas 4Qwe rty uio pas 5Qwe rty uio pas User1 Search result with “read” filtering 2Qwe rty uio pas 4Qwe rty uio pas User2 Search result with “read” filtering 2Qwe rty uio pas 5Qwe rty uio pas User1 Search result with “edit” filtering - 4Qwe rty uio pas User2 Search result with “edit” filtering - 5Qwe rty uio pas

What can you do with XACML policies? Repository-wide policy demo examples deny-apia-to-ldap-group.xml DENY access to all API-A methods to users who are “Librarians” or “Info Technologists” (as indicated by their LDAP attributes). deny-apia-if-not-tomcat-role.xml This policy will DENY access to all API-A methods to users who are NOT in the “administrator” or “professor” ROLES. deny-apia-except-by-owner.xml DENY access to all API-A methods to any user unless that user is the owner of the object being accessed. deny-objects-hide-datastreams-if-not-tomcat-role.xml The overall intent of this policy is datastream hiding, meaning that raw datastreams must not be accessible to anyone except very privileged users. Object-specific policy demo example Object-specific policies are policies that refer to one particular digital object. An object-specific policy is stored in the "POLICY" datastream of the digital object to which it pertains. demo-5.xml By using multiple policy rules, this policy shows how to DENY access to all raw datastreams in the object except to particular users (e.g., the object owners). It also shows how to DENY access to a particular dissemination to selected user roles.

What can you do with XACML policies? urn:fedora:names:fedora:2.1:action:api-a administrator professor

What can you do with XACML policies? Policy decision point (PDP) - The system entity that evaluates applicable policy and renders an authorization decision. Policy enforcement point (PEP) - The system entity that performs access control, by making decision requests and enforcing authorization decisions. Policy administration point (PAP) - The system entity that creates a policy or policy set Policy information point (PIP) - The system entity that acts as a source of attribute values e.g.authentication (AuthN) providing user attributes authorization (AuthZ)‏

Three Alternatives - Basically ➲ Post-search filtering - after search, ask deny/permit for each hit in the page - after a deny, add hit to page - no exact hit count until the end Search result - 2Qwe rty uio - 4Qwe rty uio 5Qwe rty uio Index 1Qwe rty uio 2Qwe rty uio 3Qwe rty uio 4Qwe rty uio 5Qwe rty uio Filtering 2Qwe rty uio 4Qwe rty uio 5Qwe rty uio Index 1Qwe rty uio abc 2Qwe rty uio def 3Qwe rty uio ghi 4Qwe rty uio jkl 5Qwe rty uio mno Search result - 2Qwe rty uio - 4Qwe rty uioas 5Qwe rty uioas Index 1Qwe rty uio 2Qwe rty uio 3Qwe rty uio 4Qwe rty uio 5Qwe rty uio Search result - 2Qwe rty uio def - 4Qwe rty uio jkl 5Qwe rty uio mno XACML deny for red user => filter out XACML deny for green user => filter out ➲ In-search filtering - logical partitioning of index - adding index fields corresponding to XACML user attributes - adding query conditions similarly (query rewrite)‏ - how-to verify correspondence? ➲ Pre-search filtering - physical partitioning of index - each index contains only accessible objects - at search, no filtering

Cost Model

The Conclusion is... ➲... rather inconclusive ➲ Problem more complex than anticipated ➲ Three alternative “solutions” no one close to the ideal solution ➲ Cost model indicated importance of characteristics ➲ Compromises necessary Choices depend on repository and usage characteristics Tailored application-specific shortcuts necessary ➲ Fez / FezACML – simplified XACML ➲ RAMP / muradora : XACML+GSearch post-search filtering ➲ DEFF Fedora experiment with GSearch and hybrid of pre-search and in-search filtering