1 / 11

An Investigation into 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 Investigation triggered by discussion on fedora-commons-developers list in January 2008.

zlata
Download Presentation

An Investigation into Filtering of Search Results by Access Constraints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Gert Schmeltz Pedersen and Christian Tønsberg Technical Information Center @ Technical University of Denmark funded by the DEFF Fedora project Investigation triggered by discussion on fedora-commons-developers list in January 2008 An Investigation intoFiltering of Search Resultsby Access Constraints

  2. 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 ...

  3. 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

  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 that are decisive for the choice of solution?

  5. The Ideal Solution ... • User1 Search result • with “edit” filtering • - • 4Qwe 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 • Search result • without filtering • 2Qwe 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 • The ideal solution includes: • Choice between • all search result hits • only hits accessible by the user • with “read” filtering • ( 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 • User2 Search result • with “edit” filtering • - • 5Qwe rty uio pas • User2 Search result • with “read” filtering • 2Qwe rty uio pas • 5Qwe rty uio pas

  6. 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.

  7. What can you do with XACML policies? <Policy PolicyId="deny-apia-if-not-tomcat-role"> <Target> <Subjects> <AnySubject /> </Subjects> <Resources> <AnyResource /> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue>urn:fedora:names:fedora:2.1:action:api-a</AttributeValue> <ActionAttributeDesignator AttributeId="urn:fedora:names:fedora:2.1:action:api" /> </ActionMatch> </Action> </Actions> </Target> <Rule RuleId="1" Effect="Deny"> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:not"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of"> <SubjectAttributeDesignator AttributeId="fedoraRole" MustBePresent="false" /> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag"> <AttributeValue>administrator</AttributeValue> <AttributeValue>professor</AttributeValue> </Apply> </Apply> </Condition> </Rule> </Policy>

  8. What can you do with XACML policies? Policy enforcement point (PEP) - The system entity that performs access control, by making decision requests and enforcing authorization decisions. authorization (AuthZ)‏ Policy decision point (PDP) - The system entity that evaluates applicable policy and renders an authorization decision. Policy information point (PIP) - The system entity that acts as a source of attribute values Policy administration point (PAP) - The system entity that creates a policy or policy set e.g.authentication (AuthN) providing user attributes • http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

  9. Three Alternatives - Basically • Index • 1Qwe rty uio • 2Qwe rty uio • 3Qwe rty uio • 4Qwe rty uio • 5Qwe rty uio • Search result • - • 2Qwe rty uio • - • 4Qwe rty uio • 5Qwe rty uio • Filtering • 2Qwe rty uio • 4Qwe rty uio • 5Qwe rty uio • 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 • 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? • 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 def • - • 4Qwe rty uio jkl • 5Qwe rty uio mno • Index • 1Qwe rty uio • 2Qwe rty uio • 3Qwe rty uio • 4Qwe rty uio • 5Qwe rty uio • Search result • - • 2Qwe rty uio • - • 4Qwe rty uioas • 5Qwe rty uioas • Pre-search filtering - physical partitioning of index - each index contains only accessible objects - at search, no filtering XACML deny for red user => filter out XACML deny for green user => filter out

  10. Cost Model

  11. 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

More Related