INSTRUCTIONS FOR A TYPICAL INTERACTION

 After starting to execute PolicyAuthor.jar, the first thing that will appear is
 the define roles and actions window.  Here, define the types of users that will
 be governed by the policy (roles), and the actions they will perform (actions).
 Do this by typing the names of the new roles in the "New Role:" text box, 
 pressing "Add Role" or the "Enter" key after each one.  The names you enter 
 will then appear in the list below the text box marked "Current Roles".  Repeat
 the same process on the right side to define actions.  When you have finished,
 click the "Done defining roles and actions" button at the bottom.
 
 	If you would like to follow through an example, for this step enter 
 	"Student" and "Faculty" as roles, and "View", "Submit" and "Grade" as 
 	actions.  These will be the roles and actions for a simple digital dropbox
 	and grading system.
 
 After a brief pause, the define roles and actions window will disappear, and
 the define constraints window will appear.  Currently, the PolicyAuthor only
 supports two types of high-level constraints: ConflictOfInterestConstraints,
 which represent two actions that no one person should be able to do, and 
 SeparationOfDutiesConstraints, which represent two roles that no one person
 should ever have.
 
 To add constraints, select the type of constraint from the selection box at the
 top right.  Then, select the parameters for the constraint in the selection
 box(es) below that.  When you have completed that, click "Add Constraint" to
 add it.  When you have defined all of the constraints you want, click 
 "Done Adding Constraints" at the bottom.
 
 	For our example, we will define only one constraint: a ConflictOfInterestConstraint
 	that states that "No one may both Submit and Grade".  Select "Submit" and
 	"Grade" in the correct selection boxes and click "Add Constraint".  This
 	constraint describes our intention that no one should be able to grade their
 	own submission.  Click "Done Adding Constraints" after adding this constraint.
 	
 The next window to appear will be the access control matrix editor.  In this
 window, you set the decision for each Role,Action pair.  Each cell in the
 displayed matrix represents the access control decision that will be made when
 a user with the role that labels the row attempts to perform the action that
 labels the column.  The decision can be one of: "Permit" - allow the action,
 "Deny" - prevent the action, or "Not Applicable" - some other policy must make
 the decision.  To set the value in each cell, you click the button that says
 "choose", and select the decision you would like for that cell.
 
 	For our example, we will purposely make mistakes in this portion.
 	The values for the matrix are given below.
 	
 			|	View	|	Submit	|	Grade
 			-----------------------------------
 	Student	|	Permit	|	Permit	|	Permit
 	Faculty	|	Permit	|	Permit	|	Permit
 	
 When you finish filling in the matrix, the conflict resolution window should 
 automatically pop up.  It may appear on top of the matrix editor window, so you
 should move the conflict resolution window so you can see both.
 
 The conflict resolution window shows two lists.  One is a list of conflicts,
 and the other is a list of the ways to resolve them.  The list of resolution
 options will remain empty until you select a conflict from the list.  When you
 do, two things will happen: first, the cell in the matrix that caused the
 conflict will turn red; second, a list of ways to resolve the conflict will
 appear on the right.
 
 You have two options for how to fix the given conflicts.  You can either 
 manually change the conflicting cells in the matrix, or you can select one of
 the proposed ways to solve the conflict from the list on the right and click
 "Fix the conflict using this resolver".  Continue doing this until no more
 conflicts exist, at which point a window will pop up containing the policy you
 just described in XACML.
 
 	For our example, we will first see four conflicts.  Two of them refer to the
 	fact that Student is currently able to Submit and Grade, and two of them
 	say the same thing about Faculty.  
 	
 	Start by fixing the student problem using one of the constraint resolvers.
 	Since a student should not be able to grade anything, select the conflict
 	marked as "Cell: (Student, Grade)".  You should have two options for fixing
 	the conflict on the right.  One suggests you remove the constraint, in case
 	we realized that we do, in fact, want to allow people to grade their own work.
 	Since this is not the case, we examine the second, which suggests that the
 	decision for the "(Student,Grade)" cell be changed to DENY.  Select this
 	option from the list on the right, and click "Fix the conflict using this
 	resolver".  The PolicyAuthor will make the change for you.
 	
 	Now there are only two conflicts in the list.  This time, the problem is
 	due to the fact that a faculty member may both submit and grade work.  In
 	this case, we know that we do not want a faculty member submitting work, so
 	we will change the decision for "(Faculty,Submit)" to DENY.  This time,
 	however, we will not do so by using one of the resolution options in the list;
 	instead, we will edit the matrix ourselves.  Change the decision for 
 	"(Faculty,Submit)" to DENY just as you did before, when initially defining
 	the matrix.
 	
 	Note that making this change does not update the conflict and resolver lists.
 	The PolicyAuthor allows you to fix any number of problems in the matrix
 	and then check your changes at any time by clicking "Re-check Conflicts" in
 	the conflict resolution window.  Click "Re-check Conflicts" after changing
 	"(Faculty,Submit)" to DENY.
 	
 	Now we will see one of the nuances that makes access control policy authoring
 	difficult.  Any user may simultaneously fill any number of roles, and the
 	way in which a decision is made for that user depends on the "Rule Combining
 	Algorithm" used in the policy.  For all examples in the PolicyAuthor, the
 	rule combining algorithm used is "Permit Overrides", which means that if
 	any of a user's roles is allowed to do something, the user is allowed to do
 	it.
 	
 	Here it causes a problem because any user who is both a Faculty member and
 	a student may both submit and grade work.  While we could fix this problem
 	by changing the matrix, the only way to fix the conflict would be to deny 
 	everyone's submit requests, or to deny everyone's grade requests.  Neither
 	is satisfactory, as both actions are important.  Instead, we should add
 	a constraint that no one may be both a faculty member and a student.  This
 	is one of the resolution options that shows up in the conflict resolution
 	window.  Select it and press "Fix the conflict using this resolver".
 	
WHAT WORKED

 The task model and JavaScript portion of this project turned out very well.  I
 have extensively tested the task model, and it behaves correctly.  I feel that 
 the way in which I have modeled constraints and the conflicts that arise from 
 them gives access to an excellent amount of information that could be used by
 the GUI.
 
WHAT DIDN'T

 There are two main areas of the project that I feel fell short: the GUI I 
 created, and the way in which I used the task engine.  I did not begin writing
 the GUI until late in the project, so I did not spend as much time designing it
 as I would have liked.  My disappointment with the GUI is primarily because of
 two things: the fact that the GUI is very static, and my use (or lack thereof)
 of the information I have available for conflict resolution.
 
 Because of the last-minute design and implementation of the GUI, it is not very
 dynamic.  The GUI is driven by changes in the task model, but those changes are
 very tightly controlled by each section of the GUI.  Each frame shown in the 
 GUI prevents the module that drives the GUI based on the task model from 
 changing the displayed GUI elements until it knows that the task is complete.
 This is done because my method for choosing the displayed GUI elements polls
 the task model for the current task.  By putting that thread to sleep, the
 actual GUI elements are able to ensure they are visible regardless of the state
 of the task engine.  
 
 In addition, the link between GUI frames and tasks is hard-coded in the 
 PolicyAuthor class, so changing the GUI or the task model requires 
 modifications to and rebuilding of the code base.  A similar problem exists for
 the code that drives the task model from within the GUI: those lines are 
 scattered all over the GUI code, so any changes to the task model that broke 
 the GUI would be very difficult to fix.
 
 For conflict resolution, my JavaScript code provides a lot of information about
 each conflict and its resolution options.  It would be possible, with the
 information I collect, to highlight constraints that cause problems as well as
 matrix cells, and to show the entire set of conflicts that would be resolved 
 through the application of a single conflict resolver.
 
 In terms of the actual use of the task model, I don't think that the task I
 chose is very well suited to a start-to-finish task model.  This is obvious
 from the extremely linear flow through my application.  However, I do feel
 that more sophisticated task modeling and plan recognition might be appropriate
 for portions of this task.  For example, I feel that a more sophisticated guide
 for filling in the matrix would be useful, as would one for fixing conflicts.
 In general, I don't feel that my application has reduced the complexity of
 authoring access control policies, but with better guiding agents for portions
 of the application, I think it could be.  At this point, the task model 
 primarily serves to check the status of the task via postconditions, and to
 slow down the entire application.
 
FUTURE DIRECTIONS

 There are three things I would like to see as extensions to this project.  First,
 while I don't feel that task modeling was a particularly successful technology
 for this application, I would like to see other technologies incorporated into
 a system like this.  Margrave, a system developed by Brown PLT, is an engine
 for determining the results of a change to an access control policy.  I think
 this could be used to detect a wider variety of conflicts and to do a better
 job of proposing resolution options.
 
 Second, I think that allowing the authoring tool to develop a better model of
 the user's intentions by capturing them in multiple ways is an excellent way
 to detect some unforeseen problems in access control matrices.  While the simple
 model I have implemented may not be very powerful for this task, there are
 probably more sophisticated ways that could be used to do this same thing.
 
 Third and finally, I would like to see more sophisticated plan recognition
 incorporated into a tool like this.  Professor Kathi Fisler has done some 
 research that suggests that there are very distinct ways that people think 
 about defining an access control policy.  If the usual process that each of
 these types of people followed were encoded as separate plans for authoring a
 policy, a more advanced plan recognition engine might be able to determine
 the type of person that was interacting with it, and provide guidance specific
 to that person's preferred process of authoring a policy.