This tutorial provides a guided tour of Margrave's functionality. The tutorial proceeds in two parts. Both parts shows how a system admin or a security officer might use Margrave to test and revise a simple access-control policy. In Part I, verification finds the flaws in policy. In Part II, many of the same flaws are found by change-impact analysis.
A college would like to make a central grades repository and enrollment management system. A curial part of the this system will be access-control since they would like to not only protect the privacy of records, but also enforce the college's enrollment policies.
They plan to build the system by starting with a small core and adding features. This will allow us to view their error's along the way.
The resources that will be protected are:
The actions that may be performed are:
The systems has three roles (types of uses):
The system starts with only the first two and the second one is added later as an addition.
In each XACML code directory, a XACML file RPSlist.xml exists. This file contains the base policy (start here). These files are written in the style of the XACML Profile for Role Based Access Control. Each RPS file targets requests for a single role. Each PPS file gives permissions to that role and any role that inherits permissions from that role.