In the wide area, it is vital for principals to restrict the rights they cede to their jobs. For example, when logging into a machine, a principal implicitly authorizes the machine and the local OS to speak for the principal for the duration of the login session. Whereas with private workstations, users generally have faith that the local operating system has not been compromised, confidence is more limited when using anonymous machines across the wide area, for example, to run large scale simulations. Roles associate a subset of a user's privileges with a name, allowing users a convenient mechanism for choosing the privileges transferred to particular jobs.
A principal (user) creates a new role by generating an identity certificate containing a new public/private key pair and a transfer certificate that describes a subset of the principal's rights that are transferred to that role; an OLA chosen by the principal is responsible for endorsing the certificates. Thus, in creating new roles, principals act as their own certification authority. The principal stores the role identity certificate and role transfer certificate in a purse of certificates that contains all roles associated with the principal. The purse is stored in the principal's home domain. While it is protected from unauthorized access by standard OS mechanisms, the contents of the purse are not highly sensitive since each entry in the purse simply contains a transfer certificate naming a role and potentially describing the rights associated with that role. The principal also stores each role's private key --encrypted by a password unique to the role --in the file system.
 |
CRISIS roles are more lightweight than the roles described in other security systems (e.g., [Lampson et al. 1991]). First, they can be created by the user without requiring intervention from a centralized authority, allowing the CA to remain off-line. Next, while ACLs can be modified to describe a particular role's privileges, roles can also act as persistent lightweight capabilities. The transfer certificate used to create the role can describe the exact access rights possessed by the role (e.g., read access to files A, B, and C).
Further, transfer certificates can be used to arrange roles in a hierarchy, with the principal's most privileged role serving as the hierarchy's root. Such a hierarchy can be used in two ways. In a single inheritance model, each role possesses a strict subset of its parent's privileges. Thus, ACLs can be used to describe the ``minimum'' privilege level required to access a given object (a role is given access to an object only if it is a direct ancestor of a role in the object's ACL). With a multiple inheritance model, roles can draw upon the privileges of multiple ancestors. Figure 2 presents an example of such a hierarchy and applications of the two models. The object, A, can only be accessed by Bob as Web Surfer or one of its direct ancestors (Bob at Home or Bob). The Figure also illustrates that Bob as Professor (and its descendants) inherits privileges from both Bob and the generic, Professor. This may be useful, for example, to express that professors are able to read student accounts but to allow such access to Bob only when he is acting as a professor.
In CRISIS, creating a new group is similar to creating a new role. A principal creates a new group by acting as a CA to create an identity certificate naming the new group. The creating principal then signs transfer certificates to all group members, specifying both membership and any update privileges associated with the group, for example, whether the member has the ability to add or remove other group members. The newly created group name can then appear on ACLs like any other principal name.