-
Notifications
You must be signed in to change notification settings - Fork 1
SecurityEvaluator Implementation Guidelines
The SecurityEvaluator is the interface between the security framework and the authentication and authorization components. Whenever an action is taken on a secured graph, model or associated entity calls are made to at least one evaluate() method. This provides an opportunity for the authorization component to block the action.
The SecurityEvaluator implements two levels of implementation. The shallow level checks access to collections of triples while the deep level checks access to individual triples.
The SecurityEvaluator recognizes the four actions collectively known as CRUD: Create, Read, Update and Delete, and provides hooks to restrict any or all of the actions.
The SecurityEvaluator implementation must retrieve the current user information and provide it through the interface as a java security Principal in the getPrincipal() method.
The "evaluate" method must use getPrincipal() to retrieve the principal and not depend upon a known implementation of getPrincipal() as a shortcut as there are cases where the principal to use for the evaluation is not the same as the current user.
When a secured graph or model is constructed a URI is provided to identify it. This URI is provided during calls to the SecurityEvaluator. Shallow implementations verify that the current user as identified by the getPrincipal() method has permissions to perform the action requested on the collection of triples identified by the URI.
It should be noted that while the URI is generally expected to the be the graph name, it may be any other assemblage of triples conceptually identified by the URI.
The shallow methods are:
- evaluate( Action, SecNode ) -- may the user perform "Action" on the URI identified by "SecNode"
- evaluate( Set, SecNode ) -- may the user perform all actions on the URI identified by "SecNode"
- evaluateAny( Set, SecNode ) -- may the user perform any of the actions on the URI identified by "SecNode"
In addition a shallow implementation must implement the deep implementation methods to return true.
- evaluate( Action, SecNode, SecTriple )
- evaluate( Set, SecNode, SecTriple )
- evaluateAny( Set, SecNode, SecTriple )
- evaluateUpdate( SecNode, SecTriple, SecTriple )
The deep implementation implements the shallow methods noted above as well as examining the SecTriples.
Triples collection of three SecNodes and generally correspond to the triples in the graph methods or the statements in the model methods with the following differences.
Corresponds to the Jena Node.ANY in that it represents any possible node. It is commonly used to determine if the authorization system has any constraints on a set of triples. For example the triple (subject, RDF.type, SecNode.ANY) will match any triple where the type of the subject is being set. So evaluate( Action.READ, (subject, RDF.type, SecNode.ANY) ) returns true if the user may read all of the triples that match (subject, RDF.type. Node.ANY). If the authorization system can not determine the truth of the statement it should return false, this will require each explicit triple to be evaluated.
A triple comprising three SecNode.ANY nodes is often used to determine if the SecurityEvaluator supports the deep level implementation.
Represents an anonymous node that has not yet been created. It is commonly used to determine if the authorization system has any constraints on the creation of a triple containing an anonymous node. However, it may also be used to determine if there are any constraints on the reading of triples containing anonymous nodes. For example the triple (SecNode.FUTURE, RDF.first, "testing") will generally be used to verify that the user may create a RDFList entry where the subject of the statement will be a new anonymous node. The authorization system must be able to determine the truth of the statement.