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.
<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>
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.