Secure XML Protocol

The secure XML protocol is an extension of the XML that can be used to restrict the mobs that an agent can see or write. It can also be used to prevent unauthorised agents from connecting to the blackboard.

On the agent side of the secure XML protocol there is little change to the XML protocol. The only change is that the secure protocol allows the optional setting of a password that will be sent along with the agent's name when connecting to the blackboard.

Virtually all security in the secure XML protocol is handled in the blackboard's transport layer. This is done by adding a security manager to the blackboard's transport protocol. This security manager is responsible for deciding whether an agent will be allowed to connect and what it can and cannot do with the mobs on the blackboard.

A very simple static security manager has been implemented in unsw.cse.mica.blackboard.secure.SimpleBlackboardSecurityManager. When using MicaRunner this is the security manger used. This security manager will look in the config/security dirctory of Mica.Home for its configuration files.

Verifying Agents

<agents>
    <group name="Writer" />
    <group name="Reader" />
    <group name="Guest" groups="Reader" />
    <agent name="AnAgent" password="123456" groups="Writer Reader"/>
    <agent name="AnotherAgent" groups="Guest"/>
</agents>
					

Figure 7.1. Example Agent Verification File


The SimpleBlackboardSecurityManager will look in the file agents.xml for information on allowed agents and the groups to which they belong. Groups can be defined in a hierarchy if desired. Figure 7.1 shows an example configuration file with 3 groups and 2 agents.

When an agent is declared with a password all agents attempting to connect using that name must provide the required password. If no password is given then any agent trying to use that name with a password will be refused connection.

Agents can belong too multiple groups and groups can inherit from multiple groups. To do so add a groups attribute to the tag and a space(' ') separated list of groups.

The format for the agent verification file is given in agentauthorisationrules.dtd.

When using MicaRunner the password for an agent to use can be set by adding a transport tag to the agent and setting the password attribute. This will look like this:

<agent class="MyAgent" >
    <transport password="123456" />
</agent>

Restricting Agent Actions

SimpleBlackboardSecurityManager will look in the rules.xml configuration file for the rules it uses to determine what an agent can and cannot do. An example rules file is shown in Figure 7.2.

In the rules it is possible to set whether the default is to accept or reject an action. If no default is given the default is to accept.

The rules are a list of if elements that say whether to accept or reject the action. Each if element has a condition followed by a then tag and an action. It may also have an else tag and alternate action for when the condition is false. The action can be to accept or reject or another conditional if statement.

<rules default="reject">
    <if>
        <and>
            <action type="write"/>
            <group name="Writer" />
        </and>
    <then />
        <accept/>
    </if>
    <if>
        <and>
            <action type="read" />
            <group name="Reader" />
        </and>
    <then />
        <if>
            <and>
                <group name="Guest" />
                <or>
                    <type name="classified" />
                    <slot name="classified" />
                </or>
            </and>
        <then />
            <reject />
        <else />
            <accept />
        </if>
    </if>
</rules>
					

Figure 7.2. Example Agent Rights File


There are a number of conditions that can be used the determine whether or not to accept an action. Available conditions include:

action

test if the agent is trying to read or write the mob

group

test if the agent belogs to the given group

type

test if the mob is of a given type

slot

test if the mob has a slot, can also be used to check if a slot has a specific value

and

groups a set of conditions that must all hold true

or

groups a set of conditions of which at least one must be true

not

tests that a condition is false

Each rule will be processed in order until a designation to accept or reject is found. If all rules are tried and no designation is made the default action to accept or reject will be used.

The XML format for the rule configuration file is given in agentauthorisationrules.dtd.

If an agent is allowed to read a mob it will recieve all handleNewMob, handleDeletedMob, handleReplacedMob events associated with it. It will also be able to see the mob using the readMob and mobSearch functions. The ability to write a mob includes writing the mob, deleting the mob and replacing it.