This documentation describes the set of security tools provided for use with the IPF release of the PerDiS platform. The only tool seen by the standard PerDiS user is the security shell, that allows a user to specify their identify and the role they wish to play in the system. The Template tool, Task tool and ACL Editor tool are all intended for use in a management activity.

This document contains the following sections:

Section 1, Using the security tools introduces the security tools, and discusses some of the limitations of using the tools with the IPF.

Section 2, The PerDiS Security Shell describes using the security shell to log into the PerDiS system and selecting a task and role to play in applications.

Section 3, The Template Tool describes the use of the template tool for creating task templates from which task instances may be instantiated.

Section 4, The Task Manager Tool describes using the task manager tool to create and manager PerDiS tasks.

Section 5, The ACL Editor Tool describes how to use the ACL editor to directly edit the ACLs associated with clusters.

The security tools described in the following sections are for use with the IPF version of the PerDiS platform. The IPF has no notion of task-management procedures, meaning these tools are intended for use in an ad-hoc way. This has several major implications:

Task object and template naming: When creating a task object or template, or indeed any other cluster, the user must select a name for the cluster created. This name must be a valid PerDiS URL of the form pds://<host_name>/<path_name>. It is anticipated that when a management procedure is in place, there will be allocated areas for the creation of tasks and templates, and this would be reflected in the names chosen.

Creating tasks and templates: Management procedures are also likely to specify and control who can create and manage task templates and objects. In the IPF, any user may create whatever task objects and templates they wish, and they will be assigned management rights for those clusters created. Currently, the IPF only prevents the creation of clusters with the same name, so the first person to create a cluster with a name becomes its manager. Clearly this is unsatisfactory for use in a non-research environment, and future versions of the platform will enforce controls on the management process.

Principal naming: when logging in to the PerDiS system or managing users in a task, or when assigning names to PerDiS daemons, a common naming scheme is required to avoid the same name being assigned to multiple principals. The naming scheme in the IPF is simplistic, and simply maps the name specified to a key certificate by virtue of the certificate having a matching filename. Hence any name or format of name may be assigned. The APF will contain a properly enforced naming scheme and corresponding key and certificate service.

The security shell allows the user to set their identity, and to specify the task and role they wish to play. This information is passed on to subsequently executed PerDiS-based applications.

The layout of the security shell is shown below:

The user must enter the identifier they wish to present to the PerDiS system. This identifier will be used to obtain the relevant public and private key information - a public key and private key file corresponding to the identifier entered must exist before the user can continue.

The user then selects the task they wish to log into by entering the URL of the relevant task object.

With these two pieces of information, the security shell tool retrieves from the task object specified any RoleInTask certificates applicable to the current user, and presents a list of these roles in the role combo box. The user selects an appropriate role from the list presented.

The user has two ways of starting an application. The shell tool provides a command line into which any standard command line input can be typed. Pressing the "Execute!" button will cause this command to be executed, with the application passed the specified security attributes.

Alternatively, the user may instead choose to start a command-line interpreter in a new window. The necessary security attributes are passed to this new shell, and will be passed on to any PerDiS applications executed from within it.

The template tool is employed to create and manage templates for use in instantiating tasks. The main activity of the template tool is in the administration of the categories and roles that form a template. The following section provides a run-through the use of the tool. It discusses creating a new template, but existing templates may be edited by selecting Open instead of new from the File menu.

To create a new template, after starting the Template Tool, choose "New" from the File menu, and enter a URL for the template to be created. Templates are stored in individual clusters within the PerDiS system, so the URL should specify a legal cluster name. The dialog box is shown below:

Having entered a valid URL, the tool presents a blank template, with a default category and default role show, as below:

To add a role to the template, choose Template->Add Role, and the following dialog box will appear:

The name must be a unique identifier (within the template) for the role, whilst the description is may be an arbitrary set of sentences.

Roles may be deleted by selecting Template->Delete Role. The following dialog box will appear:

The role to be deleted is selected from the list of current roles. Clicking "Delete Role" will remove the role from the template.

It is possible to browse the roles and their descriptions by selecting Templates->Edit Roles. The following form will appear. Select from the tabs at the top of the form to select the role to be displayed.

Identical functionality is available for the creation, deletion and browsing of categories.

To set the permissions a role has for a category, double click on its entry in the grid. A combo box will appear allowing you to choose from the permissions available. Select the permission to assign, and click or press enter:

When exiting the tool, if you have made modifications to the template you will be presented with the following dialog:

If you wish to retain the changes, press Commit. To abandon any changes, press Abort.

The Task Manager tool is used to create and manage tasks. Its main use is to assign users to roles in a task, but it can also be used to import and manage the task template specifying the categories for the current task.

To create a new task, start the task manager tool, and choose "New" from the File menu. Enter a suitable PerDiS URL for the task object for the task to be created:

Once a name has been selected, the user is prompted for the template the task should be instantiated from:

The user either specifies the URL for a task template, or chooses "No Template" to create a default task with a single default role and category entry.

The tool creates a new task object, and opens the default view, which for each user presents a list of the roles they are currently assigned to, and allows roles to be assigned or revoked:

The user under consideration is selected from the central combo box at the top of the form. The list of roles they are currently assigned to is shown on the left hand side of the form. The roles available for assigning in the task are presented in the right-hand side list.

To assign a role to a user, select the role to assign from the right-hand list, and then click on the ß button. The role will be assigned to the user, and will appear in the left-hand side list. A RoleInTask certificate validating the user in the role will be generated and added to the task. The certificate will be signed using the key of the task manager.

Selecting a role in the left-hand list and clicking on the à button will cause the RoleInTask certificate assigning the user to the role to be revoked.

Although a standard set of roles is provided by the task template used to instantiate the task, roles may be added or deleted from the task. Roles are created by selecting Roles->Create Role which produces the following dialog:

Enter a unique identifier for the role, and the optional descriptive details and press create. The role is added to the task's set of roles, and becomes available for assigning to users.

To delete roles from the task, select Roles ->Delete Role to bring up the following form:

Select the role to delete from the list and click Delete Role to delete it from the task. As well as removing the role from the role list and role/category matrix, and RoleInTask certificates for the role will be deleted from the task. Details of the roles can be browsed as in the Template Tool by selecting Roles->Edit Roles which brings up the following form:

An alternative view presents the information on a per-role basis, and lists the users assigned to the role and the users available for assigning to a role. Selecting Window->New User View brings up the following:

In the above view, select the role under consideration is selected from the top combo box. The users assigned to that role are presented in the left-hand box, whilst the users in the task are listed in the right-hand box. Selecting a user from the right-hand list and clicking ß assigns the user to the current role on display and generates an appropriate RoleInTask certificate. Selecting a user from the left-hand list and clicking the à button will revoke the user's assignment to the role.

Users may be added to and removed from the task in the same way as roles.

The role/category matrix active for the task may also be edited, with the same functionality as the Template Tool, by selecting Window->New Category Window. Permissions may be set by clicking in the matrix and choosing an appropriate permission. Categories may be created or deleted by choosing from the Categories menu.

The ACL editor allows for the direct editing of the ACL associated with a cluster. To edit an ACL, start the ACL editor, and enter the URL for the cluster with the ACL you wish to edit, as below:

The default entry for a cluster will depend on the entry for the category of objects the cluster is used to store. If no category is specified, the default access is for the creator (as a named principal) to have Readwrite access. The following shows a task object created by a user with identifier "cn=Marcus". Because it is a task object, it also allows Read access to any user in the task.

To assign permissions for a role, select ACL->Add Role, which produces the following dialog:

Enter the task containing the role you wish to assign access to (this will usually be pre-filled for you), select from the available roles in the combo box, and choose the appropriate permission.

Named users may also be added to the ACL by selecting ACL->Add User:

Entries may be removed from the ACL by selecting the entry to be deleted from the list and then choosing ACL->Delete Entry:

The permissions assigned to a user or role may be edited by clicking on the permissions column of the entry to be deleted, and selecting the permission required, as shown below:

Note that setting the permission to None will remove the entry from the ACL.

Upon exit from the program, modifications made to the ACL may be committed or aborted.

The Security Tools