New Security requirements for ETICS 2

Introduction

This document analyze different requirements found in https://twiki.cern.ch/twiki/bin/view/ETICS/SA23AerospaceComunityRequirements and in the documents attached to it.

Requirements already implemented

They are from previous list: R1, R2 and R7. Are implemented in release 2.4.0.

Requirements to be discuss

These are mainly from previous link: R3, R4, R5, R6 and R8.

R3: only authenticated users can access to the projects

Seems like Guest user is not usable anymore. We have 2 possible options:

• Eliminate Guest user: it is easy, but then, should we eliminate non secure access?
• Eliminate tabs for Guest user: only Welcome would be available.

This Requirement has been fulfilled. L. Dini has implemented a basic authorisation filter: Details under: https://twiki.cern.ch/twiki/bin/view/ETICS/SA1Privacy

R4: Legally aspects and R5: code protection

These two requirements represent the need of management of multiple contractors sharing a common development environment and the need of a read protection on Project, Subsystem and Component level.

There are already in the database tables projectUser, subsystemUser and componentUser. To implement these requirements we have to extend the use of that tables, to show the elements and allow access to only the parts of a project where the user is allowed. Changes in the web service are also need to be adapted to the new permissions.

To manage all this permissions the actual administration panel is not enough. A new option “Manage project permission” should be created. There, the user with rights to do it, should see a list of projects the user can manage. Inside the project window, the user can add or remove users and its permissions to each module. Inside this we can have many cases:

• Permission is granted for a user in a Project, then this permission is also added to all the subsystem and all the components. Same for subsystems and components. Later is possible delete permissions in some children of the node without modify the permission in its father.
• Permission is granted for a user in a component, then same permission is added to its subsystem and project. (if not, he is not allow to access that component)

To delete a permission in a module happens something similar:

• If a permission in a project is deleted, same permission for that user must be deleted inside all its children.

Another option is integrate in right-click submenu in Configuration tab an option to set/remove permissions.

R6: Flexibility in composing of groups

We can easily create more roles, but a big number of them can make administration quite complex. What we can do is a new table in database to allow the creation of groups. A group will be a set of users with one or more permission in a module. The problem is that nowadays a permission is granted in a specific component, so these groups can be at the end useless. Only it can be useful for modules with a big amount of users.

R8: Attachment of private repositories and worker nodes

As it is said, this requirement can only be fulfilled by attaching private repositories and worker nodes at the customers location. The ETICS system must be extended to allow the attachments of private resources (Worker nodes and Repositories). The problem here is that we should do the repository selectable and private nodes should have a certificate. Other possible solution is that after building, resources pass trough ETICS and come back to the private resource, but this cannot be enough secure for some clients.

[UMW] Re: My last informations I got on this issue is, that users who do not want to place their projects on a foreign platform will also resist on the possibility to compile on a foreign platform at all. So for the moment my suggestion is to give a very very low priority on this requirement, as it can be solved already with an own in house ETICS system.

-- Main.Uwe Mueller-Wilm - 19 Mar 2009

Other points to be discuss

Access by login/password

About the question raised about if it is possible have certificates and common user/password to access the web application, if we eliminate the guest user maybe is possible to implement it (now instead of guest user, the user must log on to use the application). The unique problem is that it will require many changes in web service, web application and also in the client.

Save user actions

We can save in a new table all actions done by the user (or only that ones considered importants). This will help in case a security problem to work as a forensic tool, to analyze which user did which action.

-- AndresAbadRodriguez - 19 Mar 2009