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 moderator, this role has been added to identify contributors (or that contributors get the fame). In contrast, the contributor cannot delete data items.
4. project responsible (Project) - is a contributor, just named differently to identify the responsible person.
5. 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.
6. 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.

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 - involves all moderators and contributors, basically all names that are named among the attributes (lead architect, project responsible, contributors)
3. Department / 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).

The access rules are implemented inlib-datahandler. In the package, com.siemens.sw360.datahandler.permissions this is implemented in ProjectPermissions. See methods isVisible and userIsEquivalentToModeratorinProject() for the actual rules.

Overall Access Matrix

	contributor	moderator	creator	user	clearing admin	admin
create	-	-	-	PCRV	PCRVL	PCRVL
read	P	P	P	(P²)CRVL	PCRVL	PCRVL
edit	PCR	PCR	PCR	-	PCRVL	PCRVL
delete	-	PCR	PCR	-	L	PCRVL

P² : only if the user is member of the group of the project (or has created the project)

Legend

acronym	description
P	project
C	component
R	release
V	vendor
L	license

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 run time, a permissions object consisting of a document and a user is created: In PermissionUtils (same package) there is a static method makePermissions<T>() that creates a permissions object. The received permissions object instance can be asked if a particular operation is allowed.

Note that the general application of these permission operations runs in the backend (Thrift services). An application in the front end of PermissionUtils for example, is for displaying buttons depending on the user main role (user, clearing admin or admin). Then the portlet makes plain use of the lib-datahandler library.

Further plans

1. Actually, creating stuff should be checked in lib-datahandler, starting with creation of licenses,which should ot be permitted to users: Issue #106

2. Issue #101 for

	contributor	moderator	creator	user	clearing admin	admin
download OSS sources	-	-	-	R	R	R
download internal sources	R	R	R	-	-	R

3. Issue #102 for

	contributor	moderator	creator	user	clearing admin	admin
send to clearing	-	P	P	-	-	PCRL

4. Issue #103 for

	contributor	moderator	creator	user	clearing admin	admin
edit clearing report	-	R	R	-	R?	PCRL