Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-326

Implement fine-grained access control

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            kohsuke 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/

            Show
            kohsuke 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/
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -
                • Issue 565 has been marked as a duplicate of this issue. ***
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Issue 565 has been marked as a duplicate of this issue. ***
            Hide
            akostadinov akostadinov added a comment -

            adding to cc

            Show
            akostadinov akostadinov added a comment - adding to cc
            Hide
            digerata digerata added a comment -

            adding cc

            Show
            digerata digerata added a comment - adding cc
            Hide
            pzajac pzajac added a comment -

            pzajac added to cc

            Show
            pzajac pzajac added a comment - pzajac added to cc
            Hide
            kohsuke 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.

            Show
            kohsuke 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.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -
                • Issue 1033 has been marked as a duplicate of this issue. ***
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Issue 1033 has been marked as a duplicate of this issue. ***
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Finally implemented in 1.164.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Finally implemented in 1.164.

              People

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

                Dates

                Created:
                Updated:
                Resolved: