Dev/omar/design/filteringService
From Omar Wiki
Contents |
Feature Overview
This feature add a new Content Management Service (CMS) called Content Filtering Service. The Content Filtering Service is configured similar to Cataloging and Validation Services on a per-ObjectType basis. However, unlike, Cataloging and Validation Services which are run by the registry during SubmitObjectsRequest processing, the Filtering Services are run at the end of the AdhocQueryRequest processing.
A Filtering Service simply filters the query results to remove and mask any sub-information within a query result that should not be visible to certain subjects (users), roles, or groups.
Motivation
- Enables a deployment to control visiblity of information at a sub-document granularity based upon identity credentials associated with the subject making a query request.
Why XACML Is Not Enough
XACML is designed to provide access control at a resource level and to Authorize or Deny an Action by a Subject. It is not designed to provide access control at a sub-resource level (e.g. element in an XML document) though perhaps XPointer based URNs could be used to identify element level resources.
The bigger issue is that what is required is not to simply Authorize or Deny a READ Action but to actually transform the query result to mask or hide the content that user is not authorized to see. This is outside of XACML AFAIK.
Use Case
ACME Corporation uses freebXML Registry to store XML Documents containing sensitive Employee information. They would like to control visibility of the information contained within these XML documents to only individuals that have specific roles. For example only the employee and their direct supervisor should be able to see the <Salary> element and its descendants. However, they do not wish to restrict READ access at the document level. Instead they wish to restrict READ access at the element or attribute level.
ACME uses the new "Role Based Content Filtering of Query Results" feature and configures the registry with a Content Filtering service that is configured for the objectType for the Employee XML documents. The Content Filtering service uses an XSLT styles sheet to filter the Employee XML document based upon the identity of the user that is retrieving the Employee document. The XSLT style sheet removes or masks those elements that the user is not supposed to see.
Whenever a user performs a query and the query matches an Employee XML document, the registry automatically invokes the style sheet configured by ACME for the Employee objectType. The Employee XML document returned is the output produced by the Employee Filtering XSLT and hides or masks the information the
Next Steps
- We need to add some static methods that can be called from XSLT to help in determining if subject is in specified role.
Feature Design
- Based on existing Content Management Services framework. This framework is quite unnecessarily complex and needs to be fixed but that is likely to be done for omar4.
- The design of the Filtering Service is very similar to the existing Cataloging Services in the following ways:
- A Filtering Service is configured in a symmetrical manner as a Cataloging Service
- There is a generic CanonicalXMLFilteringService that can be used to filter any XML content using an ObjectType-specific XSLT style sheet used as a FilteringControlFile.
- Non-XML content may be filtered using custom plugin classes or SOAP services
- Filtering services may be bypassed via a configuraion property org.freebxml.omar.server.query.bypassCMS in omar.properties similar to how Cataloging services are optionally bypassed.
- The design of the Filtering Service is different from the existing Cataloging Services in the following ways:
- While Cataloging Services are invoked by registry on publish requests, the Filtering Service is invoked on query requests just before returning the query results to the client.
- Cataloging Service currently only produce one output which is the RegistryObjectList cotaing metadata. FilteringService produces two ouputs, filtered RegistryObject metadata and filtered RepositoryItem content
- The filtering services are bypassed by default (feature is turned off) and MUST be explicitly turned ON. Cataloging services are ON by default. The reason is that query is a more performance sensitive operation and fewer deployments may use the filtering feature.
Feature Usage
- This feature is OFF by default. Turn it ON using the follwoing property in conf/omar.properties:
# # Bypass invoking Content Management Services for content and metadata filtering # upon publish if set to true # org.freebxml.omar.server.query.bypassCMS=false
Filtering XML Content Using Caninical XML Filtering Service
For XML Content simply use existing CanonicalXMLFilteringService and configure a FilteringControlFile_XXX.xsl XSLT style sheet as exemplified by the file misc/samples/cppa/InvocationControlFile_CPP.xsl. The steps are as follows:
- Create an XSLT file using misc/samples/cppa/InvocationControlFile_CPP.xsl as an example. It MUST support parameters subjectId and MAY support parameter repositoryItem.
- Define an ExtrinsicObject for the XSLT style sheet being used as FilteringControlFile. See example with id "urn:freebxml:registry:sample:profile:cpp:cms:FilteringControlFile_CPP.xsl: in misc/samples/cppa/SubmitObjectsRequest_Config.xml
- Define a FilteringControlFile Association with ExtrinsicObject for new XSLT as source and the objectType classification node for the XML type being filtered.
- Publish all of above new content and metadata to registry.
- Use Java UI, Web UI or JAXR client to issue an AdhocQueryRequest to registry and expect registry to perform filtering as configured.
Feature Testing
- Added test/org/freebxml/omar/server/cms/CanonicalXMLFilteringServiceTest.java
- To run above test with success make sure that you configure the org.freebxml.omar.server.query.bypassCMS property in conf/omar.properties to "true".
Feature Feedback
- Add your thoughts, issues and comments here. Please include email address. Thanks.
