•  
      story #12554 have private projects without restricted members
    Summary
    Empty
    have private projects without restricted members

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

    Geoffroy Grelot (ggrelot)
    Status
    Done
    Development
    Empty
    Empty
    Details
    #12554
    Manuel Vacelet (vaceletm)
    2019-04-07 01:00
    2018-11-26 17:22
    3519

    References

    Follow-ups

    • User avatar
      First steps of this story done in Tuleap 11.0.
      Remaining work has been moved to story #13237.

      • Status changed from On going to Done
    • User avatar
      gerrit #14608 integrated into Tuleap 11.0.99.9.
    • User avatar
      gerrit #14579 integrated into Tuleap 10.11.99.201
    • User avatar
      gerrit #14577 integrated into Tuleap 10.11.99.197.
    • User avatar
      gerrit #14566 integrated into Tuleap 10.11.99.194.
    • User avatar
      gerrit #14564 integrated into Tuleap 10.11.99.190
    • User avatar
      gerrit #14549 integrated into Tuleap 10.11.99.185.
    • User avatar
      gerrit #14559 integrated into Tuleap 10.11.99.183.
    • User avatar
      gerrit #14550 integrated into Tuleap 10.11.99.182
    • User avatar
      gerrit #14513 integrated into Tuleap 10.11.99.179.
    • User avatar
      gerrit #14545 integrated into Tuleap 10.11.99.175.
    • User avatar
      gerrit #14480 integrated into Tuleap 10.11.99.154.
    • User avatar

      Another bunch of AC update following implementation findings.


      • Acceptance criteria
    • User avatar
      gerrit #14467 integrated into Tuleap 10.11.99.146.
    • User avatar
      gerrit #14438 integrated into Tuleap 10.11.99.142.
    • User avatar
      gerrit #14409 integrated into Tuleap 10.11.99.130.
    • User avatar

      Update AC with today's findings


      • Acceptance criteria
    • User avatar
      gerrit #14408 integrated into Tuleap 10.11.99.119.

      • Acceptance criteria
      • Status changed from To be done to On going
    • User avatar
      @bdauton I agree with version D : in most situations, welcoming restricted users should be an explicitly chosen behaviour.
    • User avatar

      Hi there,

      Following the @ggrelot comment, I've attached two others versions. I personally prefer the version D which I find more readable.


    • User avatar
      • Acceptance criteria
    • User avatar
      • Acceptance criteria
      • CC list set to Geoffroy Grelot (ggrelot)
    • User avatar
      Reflects the submitted usecase correctly. I personnally view version 'a' of the mockup as the clearer, though it could be more consistent to display the open lock for "public including restricted' and an open lock with strikethrough 'R' for "public without restricted", i.e. similar to the proposal for private projects.
    • User avatar
      • So that
      • Acceptance criteria
      • Attachments project-locks-version-a.png, project-locks-version-b(1).png added