1. An Evaluation of Solutions to Filtering of Search Results by Access Constraints Gert Schmeltz Pedersen and Christian Tønsberg Technical Information Center @ Technical University of Denmark funded by the DEFF Fedora project triggered by discussion on fedora-commons-developers list in January 2008 investigation presented at Open Repositories, Southampton, April 2008

2. Overview ➲ The Problem ➲ Analysis ➲ Demonstration ➲ Larger-scale experiment ➲ Conclusion

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

4. 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 and their usage that are decisive for the choice of solution?

5. The Ideal Solution ➲ The ideal solution includes: Filtering mechanism must correspond to XACML access control mechanism Hits after filtering must be readable by user Objects readable by user must not be filtered out Normal paging of hits Show number of hits Supported for large number of users / (“virtual”) user groups Acceptable performance Search result without access filtering 2Qwe rty uio pas 4Qwe rty uio pas 5Qwe rty uio pas Abstract example of digital 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 access filtering 2Qwe rty uio pas 4Qwe rty uio pas User2 Search result with access filtering 2Qwe rty uio pas 5Qwe rty uio pas

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

7. What can you do with XACML policies? http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf 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)‏

8. 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 policies - adding query conditions similarly (query rewrite)‏ - correspondence only in simple cases ➲ Pre-search filtering - physical partitioning of index - each index contains only accessible objects - at search, no filtering - correspondence only in simple cases

9. Cost Model

10. Demonstration – the Smiley objects case

11. Demonstration – three user roles - postsearch

12. Demonstration setup SmileyStuff SmileyWasteb asket SmileyBeerGl ass Smiley... Demo:... in SmileyStuff (12)‏ SmileyStuff++ (13)‏ all Demo objects (25)‏ fedoraAdmin smileyAdmin smileyUser XACML policy for smileyAdmin XACML policy for smileyUser lucene for presearch Interface: SearchResultFiltering Class: SearchResultFilteringDemoImpl allFoxmlToLucene.xslt smileyFoxmlToLucene.xslt inSmileyFoxmlToLucene.xslt

13. fedora-users.xml administrator SmileyAdmin SmileyUser Demonstration setup

14. XACML policy for SmileyAdmin <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PolicyId="administrator" RuleCombiningAlgId="...:xacml:1.0:rule-combining-algorithm:first-applicable"> SmileyAdmin <SubjectAttributeDesignator AttributeId="smileyRole" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/> demo:Smiley.* <ResourceAttributeDesignator AttributeId="urn:fedora:names:fedora:2.1:resource:object:pid" DataType="http://www.w3.org/2001/XMLSchema#string"/>

15. Demonstration setup XACML policy for SmileyUser <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PolicyId="administrator" RuleCombiningAlgId="...:xacml:1.0:rule-combining-algorithm:first-applicable"> SmileyUser <SubjectAttributeDesignator AttributeId="smileyRole" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>... demo:SmileyStuff <ResourceAttributeDesignator AttributeId="urn:fedora:names:fedora:2.1:resource:object:pid" DataType="http://www.w3.org/2001/XMLSchema#string"/>

16. Demonstration setup public interface SearchResultFiltering { public String selectIndexNameForPresearch(String fgsUserName, String indexName); public String rewriteQueryForInsearch(String fgsUserName, String indexName, String query); public StringBuffer filterResultsetForPostsearch(String fgsUserName, StringBuffer resultSetXml); } /** * This demo implementation of SearchResultFiltering shall reflect the XACML policies * for the two demo smiley roles SmileyAdmin and SmileyUser */ public class SearchResultFilteringDemoImpl implements SearchResultFiltering { public String selectIndexNameForPresearch(String fgsUserName, String indexNameParam) { String indexName = indexNameParam; String userRole = getUserRole(fgsUserName); if ("SmileyAdmin".equals(userRole)) indexName = "SmileyAdminIndex"; else if ("SmileyUser".equals(userRole)) indexName = "SmileyUserIndex"; else if ("administrator".equals(userRole)) indexName = "AllObjectsIndex"; return indexName; } public String rewriteQueryForInsearch(String fgsUserName, String indexName, String query) { // query rewriting shall correspond to the additional index field(s) in the xslt indexing stylesheet. String rewrittenQuery = query; String userRole = getUserRole(fgsUserName); if ("SmileyAdmin".equals(userRole))‏ rewrittenQuery = "( " + query + " ) AND smiley AND PID:demo*"; else if ("SmileyUser".equals(userRole))‏ rewrittenQuery = "( " + query + " ) AND smiley AND PID:demo* NOT PID:\"demo:SmileyStuff\""; return rewrittenQuery; } public StringBuffer filterResultsetForPostsearch(String fgsUserName, StringBuffer resultSetXml) { StringBuffer result = resultSetXml; // foreach hit in resultset, evaluate XACML policies, if not deny (~permit) then include in result... }

17. Demonstration setup Indexing stylesheet for administrator... <xsl:if test="not(foxml:digitalObject/foxml:datastream[@ID='METHODMAP'] or foxml:digitalObject/foxml:datastream[@ID='DS-COMPOSITE-MODEL'])">... Indexing stylesheet for SmileyAdmin... <xsl:if test="not(foxml:digitalObject/foxml:datastream[@ID='METHODMAP'] or foxml:digitalObject/foxml:datastream[@ID='DS-COMPOSITE-MODEL'])">... Indexing stylesheet for SmileyUser... <xsl:if test="not(foxml:digitalObject/foxml:datastream[@ID='METHODMAP'] or foxml:digitalObject/foxml:datastream[@ID='DS-COMPOSITE-MODEL'])">...

18. Demonstration – three user roles - insearch

19. Demonstration – three user roles - presearch

20. Larger-scale experiment - setup from Databases Danish Research objects userRolejIndex userRoleiIndex allObjectsIndex many user roles XACML policy for user role i XACML policy for user role j lucene for presearch Interface: SearchResultFiltering Class: SearchResultFilteringEvalImpl allFoxmlToLucene.xslt userroleiFoxmlToLucene.xslt userrolejFoxmlToLucene.xslt 130.000

21. Conclusion ➲ The investigation and analysis clarified important aspects Three alternative approaches, no one close to the ideal solution Cost model indicated importance of characteristics Tailored application-specific shortcuts necessary ➲ The demonstration implementation has pinpointed details of the approaches The most significant and difficult aspect in in-search and pre-search is how to map from policy to index creation and further for in-search how to rewrite queries This indicates that policies must be kept simple For post-search, policy check for each hit is costly ➲ A larger-scale experiment on a large repository with many user roles underway ➲ Next version of GSearch to include search result filtering, October-November 2008.