story #12554 have private projects without restricted members
    have private projects without restricted members

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


    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".

    Geoffroy Grelot (ggrelot)
    • [ ] Does it involves User Interface? 
    • [ ] Are there any mockups?
    • [ ] Are permissions checked?
    • [ ] Does it need Javascript development?
    • [ ] Does it need a forge upgrade bucket?
    • [ ] Does it need to execute things in system events?
    • [ ] Does it impact project creation (templates)?
    • [ ] Is it exploratory?
    Manuel Vacelet (vaceletm)
    2019-04-07 01:00
    2018-11-26 17:22

    Referencing story #12554

    Git commit