Difference between revisions of "OTEquinox/Aspect Binding Negotiation"

Revision as of 16:19, 22 March 2015

Introduction

Roles in OT/Equinox may have specific privileges regarding their base classes, which allows them to by-pass standard visibility rules. Aspect binding negotiation is a concept by which any desired level of security can be achieved on top of the mechanisms of decapsulation.

Two kinds of aspect permissions are distinguished:

1. The permission to define an Aspect Binding to a given base bundle
2. The permission to apply Forced Exports to a given package of a base bundle

forced exports are unimplemented in OTDT 2.3.x, see bug 413862 -- OTDT 2.4 will bring back this feature.

Aspect permissions can be configured at these levels:

1. Granting of forced exports by entries in config.ini which apply to a given Eclipse installation (all users, all workspaces)
2. General workspace configuration defines the defaults that apply to aspect bindings and forced exports respectively, in case no other statement is made.
3. Specific workspace configuration can be used to grant or deny individual aspect bindings and or forced exports.
4. Participants in a negotation protocol dynamically vote which aspect permissions should be granted at runtime.

Aspect permissions are combined in a three-valued logic of DENY, GRANT, UNDEFINED, where DENY has highest priority, UNDEFINED lowest. This means a single DENY suffices to strictly disallow a requested aspect binding (or forced export). In order to grant an aspect permission, at least one GRANT vote must be given.

Installation-wide configuration

For this level of configuration please see Forced Exports.

General workspace configuration

A simple textfile in the workspace defines the defaults for aspect permissions. It is located in

<workspace>/.metadata/.plugins/org.eclipse.objectteams.otequinox/negotiationDefaults.txt

At the first use of a workspace this file is initialized with the following content:

aspect.binding.default=GRANT
forced.export.default=UNDEFINED

Manually changing the second line to forced.export.default=GRANT, e.g., would effectively grant all forced-exports request.

Specific workspace configuration

OT/Equinox may store specific permissions for specific requests in the workspace. The format of this is, however, subject to future changes. All files are located inside the following directory:

 <workspace>/.metadata/.plugins/org.eclipse.objectteams.otequinox

For aspect bindings two files grantedTeams.txt and deniedTeams.txt are used. The file format is line based, with each line consisting of

• aspectBundleSymbolicName->baseBundleSymbolicName=team1QualifiedName,team2QualifiedName...

For forced exports two files grantedForcedExports.txt and deniedForcedExports.txt are used internally, which use a syntax similar to what is used in Forced Exports.

Dynamic Negotiation

OT/Equinox provides the extension point

org.eclipse.objectteams.otequinox.aspectBindingNegotiators

• See also the extension point documentation.

Extensions to be registered at this extension point must implement the following interface:

public interface IAspectRequestNegotiator {
 
        /** 
         * Check whether a request for forced exports should be granted.
         * @param aspectBundleSymbolicName the aspect issuing the request
         * @param baseBundleSymbolicName   the affected base bundle
         * @param basePackage              the affected base package
         * @param previousNegotiation      the result of negotations up-to this point
         * @return a structure holding the answer, must not be null.
         */
        AspectBindingRequestAnswer checkForcedExport(String aspectBundleSymbolicName, String baseBundleSymbolicName, String basePackage, AspectPermission previousNegotiation);
 
        /** 
         * Check whether a request for an aspect binding should be granted.
         * @param aspectBundleSymbolicName the aspect issuing the request
         * @param baseBundleSymbolicName   the affected base bundle
         * @param teamClass                an affecting team class involved in this aspect binding
         * @param previousNegotiation      the result of negotations up-to this point
         * @return a structure holding the answer, must not be null.
         */
        AspectBindingRequestAnswer checkAspectBinding(String aspectBundleSymbolicName, String baseBundleSymbolicName, String teamClass, AspectPermission previousNegotiation);
}

where an AspectBindingRequestAnswer is defined by

public class AspectBindingRequestAnswer 
{
        /** Should this answer be remembered persistently? */
        public boolean persistent;
        /** Should this answer be applied to all subsequent requests? */
        public boolean allRequests;
        /** The actual answer. */
        public AspectPermission permission;
}
public enum AspectPermission {
        /** Not influencing negotiation between other parties. */
        UNDEFINED,
        /** A permission is granted unless someone else denies it. */
        GRANT, 
        /** A permission is explicitly denied. Cannot be overridden. */
        DENY;
}

Whenever the OT/Equinox runtime encounters an aspect binding or the request for a forced exports it iterates all registered negotiators until either a DENY has been received or all negotiators have cast their vote. By setting the persistent flag to true, a negotiator tells the runtime to store this particular vote.

Example: org.eclipse.objectteams.otequinox.aspectasker

Needs update
The plugin described here is currently not maintained due to pending issues observed on MacOS

An example plugin is provided that interactively asks the user to vote GRANT, DENY or pass unchanged (UNDEFINED). This demonstrates how the extension point can be used to give the control to the end user, who will have to deny or grant each single request at least once.

Other plugins can contribute to this negotation using other strategies. Even cryptographic protocols which involve checking of specific certificates etc. can easily be plugged into the OT/Equinox runtime.