I can ensure external people won't have access to sensitive informations

Overview

As of today, when platform is configured to mandate login, there are 3 levels of project

• public incl. restricted: all authenticated users can access the project
• public: accessible only by active users
• private: accessible only be project members

It's proposed with this story to

• add a 4th level: "private without restricted".
  • project admins cannot add as member someone who is restricted
• have 4 different icons that allows to clearly identify each level

Acceptance criteria

• Project admin can no longer add restricted users to project members (and user groups)
  • Users are not proposed in autocompletion
• Restricted users that try to access a "private w/o restricted" project doesn't have the possibility to request access, they are getting a 404 error.
• When a user is switched to restricted, the user is removed from all projects that are "private w/o restricted" (and all user groups)
  • There is a warning message to confirm the action (User is going to be removed from X projects).
• When a project is switched to "private w/o restricted", all restricted users are removed from project members (and all user groups)
  • There is a big warning message specific to this switch to confirm (when there are restricted): "X users are going to be removed from this project".
• Binding of user groups must filter restricted users when target group is a "private w/o restricted" project.
• On LDAP sync of user groups, the users are filtered to remove restricted that should land in "private w/o restricted" project.
  • Warning, user filters (that control how users are created/updated on the platform from LDAP) must be applied before the "private w/o restricted" filter.
• XML export
  • When platform is configured with access to "Anonymous" or "Authenticated", project are exported like
    • public
    • private
  • When platform is configured with access to "Autenticated + Restricted", projects are exported like
    • public-with-restricted
    • public
    • private-with-restricted
    • private
• XML import should reject creation that doesn't comply with constraint
  • When platform is configured with access to "Anonymous" or "Authenticated", projects can be imported with following access level (other levels trigger an error):
    • public
    • private
  • When platform is configured with access to "Autenticated + Restricted", projects can be imported with following access level
    • public-with-restricted
    • public
    • private-with-restricted
    • private
• SOAP and REST API must also enforce the constraint
• The 4 level of project access must be managed a project creation
  • Should be proposed in the web UI
  • Should be managed as default value for project creation
    • The local.inc config "$sys_is_project_public = 1;" is put in the DB (and can manage de 4 possible default values) and managable by the web ui and "tuleap set-config" CLI

Implementation concerns

The implementation is done with double safety in mind (aka ceinture & bretelles). That means that, in addition to ensure that when a user becomes restricted or when a project becomes private (w/o restricted), the people are removed from said projects. In addition to that, the implementation is done so if it ever happens that a restricted user ends-up being member of a private (w/o restricted) project, the checks are there to ensure they still cannot access it.

However this comes at a cost and limitations. The main limitation is that it cannot work for all UNIX related features:

• proftpd plugin
• direct ssh or ftp access
• cvs support

For those services, the only protection that will apply is "restricted users are removed from private projects".