In BSCW, access rights are determined by the role or roles that a user holds. A role has a name and is defined by a set of actions that are allowed for a user that plays that role. In principle, action control with roles is very simple: In order to decide whether a user may perform an action on a certain object, you have to check whether the action is contained in any role that the user plays with respect to this object.

There are a number of roles you might be familiar with as a BSCW user: member, restricted member, and manager of a workspace or document, owner of an object. How does a user get to play these (and other) roles?

To start with, every user is made the manager of his home folder, clipboard, and waste basket when he registers as a BSCW user. When a user creates an object, he is made the owner of this object. Users and whole workspace groups may be added to a workspace in a specific role (by default in the member role)

In order not to necessitate to much role assignment when creating new folders, role definition and role assignment for most roles are inherited along the containment hierarchy (for exceptions see below). When you create a subfolder of a folder where you have this right, the workspace group of the new subfolder is the same as in the parent folder including the role assignments, i.e. the managers of the parent folder will also be the managers of the subfolder etc.

Members of a workspace with the necessary access rights (usually managers) may change the role assignment of members of a workspace, e.g. make an ordinary member a manager.

The role of restricted member is automatically assigned to anyone accessing the publicly available parts of a BSCW server via the public entry point, but of course may also assigned to other members of a workspace.

In addition to the the pre-defined standard roles that are available in every workspace, users may define roles of their own in a workspace which are then only available in that particular workspace and its subfolders. You must also note that role definitions may be changed in a workspace, which goes for standard roles as well as for user-defined roles. This way access rights may be extended or restricted for individual folders by redefining a role or by changing the assignment of roles to folder members. What is allowed for a member of one workspace may not be allowed for a member of another workspace. What actions exactly are allowed for an user is shown on the info page of an object: for every defined role the actual set of actions is listed (see 4.6).

There are different types of roles in BSCW.

• First, there are roles that do not only apply solely to a certain object where defined but are inherited via the containment relation along the workspace hierarchy unless redefined. The pre-defined roles manager and member and all user-defined roles behave that way. Therefore (and for lack of a better name) they are called 'normal' roles.
• Second, there are roles which cannot be inherited via the containment relation because it makes no sense: currently, these are the roles of an owner of an object which grants specific access rights with regard to the object owned, and the role of a registered user which grants access rights without reference to a certain object (currently, by default this amounts to nothing, but can be redefined to allow, e.g. very general information rights). Clearly, these roles cannot be inherited along the folder hierarchy, and hence are called 'non-inheritable roles'.
• Third, there are roles that feature a fixed assignment in the sense: Once you play that role in a group you keep it whatever happens with that group, i.e. if the group is invited as managers to a folder and you play a fixed role, you keep the fixed role and are not promoted to a folder manager like the others that do not play fixed roles. There is only one pre-defined 'fixed role', the restricted member role mentioned above.

A BSCW user may hold multiple roles in parallel, e.g. a user may be the member of a workspace and the owner of an object contained in that workspace.

The current access rights of a user are determined as the union of the actions specified by the roles that he plays. By way of this definition a user may hold access rights that a single role does not specify. The owner of a note in a discussion, e.g., may edit this note, what the member role does not allow; on the other hand he may not release the note (in a moderated discussion) according to his owner role, but is allowed to do so via the member role.

Normal roles

Normal roles comprise the pre-defined roles 'Member' and 'Manager' plus all user-defined roles. All registered users hold the role `Manager' in their top level folders (Home, Clipboard, Wastebasket, Calendar) and inherit this role in all folders they create below their home folders.

The definition of pre-defined normal roles may also be changed within the folder hierarchy, so the 'Member' role, e.g., does not comprise the same set of actions in every folder. The current definition of a normal role that a user holds, i.e. the set of permitted actions, are determined by the next containing folder in the folder hierarchy in which the role was defined or modified. If the role, e.g., is a pre-defined role that was never modified, the role definition of the (top level) home folder is taken.

The inheritance of the role definitions is established when the subfolder is 'linked' into its parent folder (via creation or movement).

Non-inheritable roles

There are currently two pre-defined roles of this type: 'Owner' and 'Registered user'. The owner role is relative to single objects, it is clearly not inheritable along the folder hierarchy since when you are the owner of a folder, you do not necessarily own all objects contained in that folder. The owners of an object are stored in a separate owner list (cf. action 'Owner'). When a new object is generated by a user, this user is entered as primary owner into the owner list of the new object, and usually this primary owner will remain the only one. The primary owner is responsible for the 'costs' caused by an object (disk space used by the object will be billed to the owner's quota) and the final destroying of an object. Only owners may change the ownership of an object (action  Owner   ).

The role 'Registered user' defines the general access rights for all (not anonymous) registered BSCW users. As default this role initially does not include any right of its own. Overriding of this initial setting should be done carefully.

Fixed roles

There is currently only one role with fixed assignment: 'Restricted member'. This role is automatically assigned to users logging in via the public entry point ('anonymous users') and allows only a very restricted set of actions (as its name suggests). The role may also be assigned to other users invited to a workspace. As soon as the role 'Restricted member' is assigned to a user, the access rights of the user are limited to the actions of this role. That means that the access rights for an object are not computed as the union of the actions of the different roles that the user holds - as described above - but are restricted to the actions of the role 'Restricted member'. Also if a whole workspace group is invited to another workspace in a certain role, e.g. as 'Manager', all members of this group that have the role 'Restricted member' will keep this role and will not be promoted to a manager (hence the name 'fixed' role). These mechanism will be applied to any role of this type that may be defined in the future.

Extended access rights for the BSCW administrator

BSCW administrators may always execute the actions 'Change role', 'Assign role' and 'Owner' on all folders, independent of their membership. Besides they may execute the action 'More information' for all objects, and have the right to open all folders.

Because of the extensive rights that a BSCW administrator has (and must have), the administrator is not a role in the sense of the BSCW role concept for security reasons. It must be avoided under all circumstances that the property of being a BSCW administrator can be manipulated from the user interface.