Reasoning Core
The Reasoning Core (RC) is the key component of the Proteus middleware as it implements Proteus context-aware policy evaluation model. RC main subcomponents are the Ontology Manager, the Dependency Manager, the Reference Resolver, the ABox Generator, the Reasoning Engine and the Reasoning Core Controller (as shown in Figure 5.5, where arrows indicate control flows).
Figure 5.5: Proteus Reasoning Core main components.
The Ontology Manager manages ontology loading, installation and removal by coordinating with the Dependency Manager, which keeps track of dependencies between ontologies, such as import relationships, and the Reference Resolver, which actually retrieves ontologies from their identifying URIs, either locally or remotely.
The ABox Generator interacts with the Context Manager to be provided with assertions about the current state and to notify CM about newly installed context ontologies.
Fact assertions about the current state are encoded in the form of (subject, predicate, object) triples, which can be either asserted or retracted. The ABox Generator is responsible for checking consistency of current state assertions, especially in case fact triples are retracted.
Let us note that ABox Generator serves as a mediator between the actual reasoner and the context source, in order to avoid inconsistencies within the knowledge base used by the reasoner that would compromise the correct inferencing process. The ABox Generator can query CM to perform reasoning about a specific access request or subscribe to CM to be notified about changes in relevant context information. The Reasoner element realizes the wrapping of the actual inference engine, which in the current implementation is the Pellet
DL reasoner [8], accessed via OWL-API. Pellet has a preliminary implementation of a direct tableau algorithm for a DL-safe rules extension to OWL-DL. This implementation allows to load and reason with DL-safe rules encoded in SWRL, although some features of SWRL are not supported. By relying on Pellet combined DL and DL-safe rules reasoning support, the Reasoner is able to determine currently active protection contexts and policies according to the policy refinement and evaluation steps described in Sections 5.3.2 and 5.3.2. The Pellet instance also contains a repository for policy and context ontologies, stored in an internal format (the TBox), as well as a repository for asserted facts describing the current state (the ABox). Let us note that within an access control session, the TBox, which defines policy and context concepts, remain unaltered, while the ABox describing facts might change at each access request. Thus, to improve reasoning performance, the Reasoner also includes a local cache, where the TBox is stored in the OWLAPI format at policy installation time.
This allows the Reasoner to only reload the ABox OWL ontologies at query evaluation time without having to parse again the TBox OWL context and policy ontologies, which can be directly accessed from the OWLAPI repository, thus saving time and bandwidth.
The Reasoning Core Controller is in charge of managing RC by coordinating ontology installation and removal, by keeping the state of the RC component monitored and by interacting with the Policy Enforcement Manager in case of incoming assess control requests. In the current implementation, RC is queried at access request time by PEM.
Upon receiving a request for evaluation, the RC Controller coordinates with CM via the ABox Generator to be provided with up-to-date state information.
Context Manager
The Context Manager has been implemented by integrating with the context man-agement and provisioning framework Contory [84]. Contory supports multiple context
pro-visioning strategies, namely internal sensors-based, external infrastructure-based, and dis-tributed provisioning in ad hoc networks. In the current implementation, we only support infrastructure-based context acquisition by means of a context server. We are working on implementing context acquisition from internal sensors, where sensors, in a loose meaning, are software applications that, deployed on board of user devices, provide context infor-mation, such as a calendar showing user activities. Contory is queried via its SQL-like declarative language.
CM performs context processing to aggregate simple context information, as pro-vided by the Contory interface, into higher level expressions, which are formalized according to a Description Logic formalism. In particular, as described above, CM produces OWL assertions, in the form of (subject, predicate, object) triples. Let us note that Proteus only defines a policy and a base context ontology, while application-dependent context ontologies must be added for any specific access action to be controlled. For example, to control ac-cess actions to a file via the File Transfer Protocol, it is neac-cessary to define an FTP-specific context ontology including concepts such as file, transmission protocol, server and client.
For any application-specific context ontology that is installed in the Reasoning Core, the corresponding context acquisition module must implemented and added to CM. In particu-lar, this module must implement data processing functionalities according to the semantics encoded in the corresponding context ontology. At present we have implemented a simple context ontology describing access to a file within a Java application2. Let us note that no addition is required when new policies are installed in the system.
To allow the addition of context processing components, CM is built according to a modular structure. CM also provides a repository of available context acquisition module implementations, each one associated with the corresponding context ontology. CM can
2Our ontologies are available at http://www.lia.deis.unibo.it/research/Proteus/ontologies
provide context information either on-demand, such as in the case it is directly queried by the ABox Generator upon receiving an access request evaluation query, or according to an event-based strategy, for example in response to relevant changes in context information, as provided by context sources. In the latter case, CM supports a callback mechanism to let the ABox Generator register and be notified about variations in specific context data.
Policy Installation Manager
The Policy Installation Manager consists of two sub-components, namely, the Mas-ter Coordinator and the Policy Specification Tool.
The Master Coordinator (MC) is responsible for managing policy/context on-tologies and for coordinating interaction between the middleware components. In particular, MC allows to configure the Proteus middleware to control access in a specific application setting by loading domain context ontologies into the PRM repository, and to install de-sired access control policies. In addition, for any new application-specific context ontology added to Proteus knowledge base, MC interacts with CM to add the corresponding context acquisition module. Once started the system, MC is in charge of coordinating PEM and PRM instances by dispatching access requests from PEM to PRM.
The Policy Specification Tool (PST) supports the definition of access control policies by providing tools for policy specification, modification, checking for correctness and installation. PST provides templates to specify OWL policies to relieve non technical users from the burden of mastering OWL complexity and to check policy specification compliance to Proteus policy and context ontologies. The Policy Specification Manager consists of a user-friendly interface that dynamically loads policy and application-specific context ontologies and present them to the user by means of structured representation.
Our implementation of PST is based on previous relevant work in the area of semantic
policy specification interfaces, mainly due to the KAoS framework [101]. At present PST user-friendly interface only supports the specification of simple access control policies, while more complex ones can be defined by directly editing and loading OWL ontologies.
Policy Enforcement Manager
Policy enforcement is a strongly application-dependent issue. Therefore, the Policy Enforcement Manager includes different sub-components, namely Enforcers, Service Prox-ies and the Service Proxy Manager. Enforcers are responsible for monitoring controlled applications, intercepting each tentative access action and allow or deny the action based on the Proteus access control decision. Each Enforcer is implemented for a specific access action. We have currently implemented Enforcers to control access to files and communica-tion channels (sockets) within a Java applicacommunica-tion by extending the Java Security Manager and re-implementing its methods [47].
Each Enforcer directly interacts with a dedicated Service Proxy (SP) instance, which mediates the interaction with the rest of Proteus middleware. Whenever a SP receives a request for access control evaluation from its corresponding Enforcer, it collects from the Enforcer relevant data about the request, such as the requestor’s identity and the accessed resource, processes this information and passes it to the Service Proxy Manager. More in detail, the Service Proxy is in charge of translating request data encoded in an application-specific format into OWL assertions, according to the context ontology defined for that application.
Finally, the Service Proxy Manager is responsible for the installation and man-agement of Service Proxies. Similarly to the case of CM, when a new application-specific context ontology is installed in the system, a dedicated SP must be implemented and added to PEM. In particular, when the SP Manager receives from the Master Coordinator a
re-quest for installation of a new Service Proxy, it looks for an appropriate SP instance in the SP repository. Once retrieved an appropriate one, it instantiates it into the system. Let us note that a Service Proxy is identified by means of a unique URI within the repository. At access request time, the SP Manager coordinates and dispatches Service Proxy requests for access control evaluation to the Reasoning Core via the Master Coordinator.