• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      Currently Hudson is configured to recognize JavaServlet view of authenticated
      users. In the setup module a user can request hudson to enable security or
      eschew it.

      I would like to see 2 options for enable security:

      Option #1: Require a user to have an admin role in order to launch a build or
      configure anything. This option is supproted today.

      Option #2: Forbid un authenticated users from seeing any information about the
      hudson configuration and/or projects. Currently I can have this effect by
      modifying build.xml to set the protected URL to / but I get the undesirable side
      effect of requiring authentication to even see the graphics on the login page.

      This feature is important to users who have internet accessible Hudson sites.

          [JENKINS-326] Implement fine-grained access control

          Hudson currently only has a very limited notion of security. Basically, you are
          either an admin or not, and admin can do anything but users can't do much.

          We obviously need more fine-grained access-control and authorization, such as:

          • allowing user X to configure project A and B, but not C
          • allow user Y to trigger a build, but not for user Z.

          Other access control requests made in the past includes:

          • ability to browse workspace files

          So I'm going to use this issue to keep track of this request, which is a
          superset of the original issue.

          One design consideration is whether to delegate the authentication to the
          container (like we do today), or handle that by ourselves. The latter would
          allow Hudson to present UI like "register" and so on, but the former would be
          easier.

          A potentially useful library: http://www.acegisecurity.org/

          Kohsuke Kawaguchi added a comment - Hudson currently only has a very limited notion of security. Basically, you are either an admin or not, and admin can do anything but users can't do much. We obviously need more fine-grained access-control and authorization, such as: allowing user X to configure project A and B, but not C allow user Y to trigger a build, but not for user Z. Other access control requests made in the past includes: ability to browse workspace files So I'm going to use this issue to keep track of this request, which is a superset of the original issue. One design consideration is whether to delegate the authentication to the container (like we do today), or handle that by ourselves. The latter would allow Hudson to present UI like "register" and so on, but the former would be easier. A potentially useful library: http://www.acegisecurity.org/

              • Issue 565 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 565 has been marked as a duplicate of this issue. ***

          akostadinov added a comment -

          adding to cc

          akostadinov added a comment - adding to cc

          digerata added a comment -

          adding cc

          digerata added a comment - adding cc

          pzajac added a comment -

          pzajac added to cc

          pzajac added a comment - pzajac added to cc

          This needs to be implemented in such a way that plugins could define the
          additional access controls.

          My current thinking is to do this at stapler level so that we can control who
          can traverse what object reference. Annotations should be a piece of this
          solution, too.

          I also want to use a library like acegi security so that we don't need to
          support container-based security model that is different from app server to app
          server.

          If anyone wants to volunteer, that would be great.

          Kohsuke Kawaguchi added a comment - This needs to be implemented in such a way that plugins could define the additional access controls. My current thinking is to do this at stapler level so that we can control who can traverse what object reference. Annotations should be a piece of this solution, too. I also want to use a library like acegi security so that we don't need to support container-based security model that is different from app server to app server. If anyone wants to volunteer, that would be great.

              • Issue 1033 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 1033 has been marked as a duplicate of this issue. ***

          Finally implemented in 1.164.

          Kohsuke Kawaguchi added a comment - Finally implemented in 1.164.

            Unassigned Unassigned
            pmendelson pmendelson
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: