Dev Role Authorisation Model

SW360 role authorization model

The following table presents the SW360 Role-Authorisation-Model.

The row specifies which action to take, the column the role of the actor. Cell entries specify which entity type can be acted upon.

There are two main types of roles. The first type are general roles on the system that apply in the default case:

1. user - a user is the default, in order to apply modifications, a user can pose moderation requests, except for the data items that a user has created.
2. clearing admin - a clearing admin has the rights to work on the projects of the own group and to edit licenses
3. admin - an admin has full rights on all data items

In addition there are ACL-style roles, meaning that per data item access settings can be made:

1. creator - a creator can modify in addition to the user's read abilities, a user can be creator of a data item
2. moderator - a creator can define moderators for a data item. Moderators can change a data item as a creator can.
3. contributor (Component) - is a contributor to a component, project, similar (but not the same) to a moderator. In addition to contributor, this role has been added to identify contributors (or that contributors get the fame). In contrast, the contributor cannot delete data items.
4. co-moderator - deprecated, should be pulled off. does not make sense anymore.
5. project responsible (Project) - is a contributor, just named differently to identify the responsible person.
6. lead architect (Project) - is a contributor, just named differently to identify the responsible person. an architect refers to the person who has that role of the project or product. This role has been added to identify architects to have a contact person for technical questions.
7. contact (Release) - deprecated, should be renamed to contributor see #100.

group (department), contributor, moderator and owner roles are entity specific, user, clearing admin and admin are roles assigned to a user.

Technical Info

The role access rules are put into lib-datahandler. In the package, com.siemens.sw360.datahandler.permissions there are implementing classes of a template class DocumentPermissions. As an example, ProjectPermissions extends abstract class DocumentPermissions.

At runtime, a permissions object consisting of a document and a user is created. This object is evaluatd by a DocumentPermission instance.

In PermissionUtils (same package) there is a static method makePermissions<T>() that creates a permissions object. With the received permissions object, the referring instance of a documnt permissions class can be asked if a particular operation is allowed.

Additional Project Visibility

In addition to the roles mentioned above, each project has a separate visibility setting (technically an attribute of the project document). There are four project visibility levels:

1. private - no one but the creator can read.
2. me and moderators - as the name says.
3. Departmnt / Business unit (should be renamed) - refer to the group the users are in.
4. Public - all registered users of the liferay / sw360 application (login required).

	business unit	contributor	moderator	creator	user	clearing admin	admin
create	-	-	-	-	PCR	PCRL	PCRL
read	P	P	P	P	CRL	PCRL	PCRL
edit	-	PCRL?	PCRL	PCRL	-	L	PCRL
delete	-	-	PCRL	PCRL	-	L	PCRL
edit users	-	-	PCRL	PCRL	-	-	PCRL
send to clearing	-	-	P	P	-	-	PCRL
edit clearing report	-	-	R	R	-	R?	PCRL
download OSS sources	-	-	-	-	R	R	R
download internal sources	-	R	R	R	-	-	R

legend

acronym	description
P	project
C	component
R	release
L	license
?	unsure