Skip to end of metadata
Go to start of metadata

Plugin Information

View Authorize Project on the plugin site for more information.

Configure projects to run with specified authorization.

What's this?

This plugin provides following features:

  • You can configure projects to have their builds run with specified authorization.
  • Provides following ways to specify authorization.
    • Run as the user who triggered the build.
      • Does not work for scheduled, or polled builds.
      • Configuring projects are allowed only to users with the BUILD permission.
    • Run as anonymous.
    • Run as the specified user.
      • You are requested to enter the password of the specified user except following cases:
        • You are an administrator.
        • You are the specified user.
        • The specified user is not changed from the last configuration, and "No need for re-authentication" is checked.
          • This can threaten your Jenkins security. Be careful to use.
      • Configuring projects are allowed only to administrators and the user configured as the authorization.
        • "Don't restrict job configuration" allows other users (with the CONFIGURE permission) to configure the project. Ensure that only appropriate users have CONFIGURE permission for that project.
    • Run as SYSTEM
      • This is provided only to cancel the global configuration. SYSTEM authorization is often considered as "unconfigured", features provided by plugins may treat it as anonymous.
  • Provides an extension point to add new ways to specify authorization.

Screenshots

  • After installed Authorize Project plugin, you will find "Access Control for Builds" in "Manage Jenkins" > "Configure Global Security". Adding "Configure Build Authorizations in Project Configuration" enables Authorize Project plugin.
    • You can also disable specific strategies in this page. Disabled strategies are never used for authorization.
  • A new side bar menu "Authorization" will appear in project pages.
  • You can select how to authorize builds of the project in the "Authorization" page.
  • When selecting "Run as Specific User", you can enter User ID with whose authorization builds will run. If you enter a user ID except yourself and have no administrative privilege, you are required to enter the password of that user.
    • You can also use API token, especially for non password-based security realms.
  • Configuring project settings by unauthorized users are forbidden when you configure the authorization for the project. See #What's this? for details.

Extension point

A new way to authorize projects can be added with extending org.jenkinsci.plugins.authorizeproject.AuthorizeProjectStrategy, overriding the following method:

public abstract Authentication authenticate(hudson.model.AbstractProject<?, ?> project, hudson.model.Queue.Item item);

Use AuthorizeProjectStrategyDescriptor for Descriptor.
If you want to provide global configuration properties, do as following:

  • global-security.jelly is displayed in "Configure Global Security" page.
  • Override AuthorizeProjectStrategyDescriptor#configureFromGlobalSecurity to save configuration.

Issues

To report a bug or request an enhancement to this plugin please create a ticket in JIRA (you need to login or to sign up for an account). Also have a look on How to report an issue

Key T P Summary
Loading...
Refresh

Change Log

Version 1.3.0 (Feb 12, 2017)

Version 1.2.2 (May 28, 2016)

  • Fixed: Builds aren't start when security realm fail to find the user for authorization (e.g. Bind DN is not set for Active Directory plugin) (JENKINS-34279)

Version 1.2.1 (Apr 03, 2016)

  • Fixed: password / api token fields for "Run as Specific User" are broken JENKINS-33897

Version 1.2.0 (Mar 27, 2016)

  • Targets Jenkins 1.625
  • SECURITY FIX: Reject unauthenticated configurations via REST / CLI (JENKINS-28298)
  • Support global default authorization strategy (JENKINS-30574)
  • Displays an error when a built-in user is used for "Run as Specific User" (JENKINS-32769)
  • Added "Run as SYSTEM" (JENKINS-32770)
    • Disabled by default for projects. You have to enable it in the global security configuration page.

Version 1.1.0 (Aug 9, 2015)

  • Added a feature to enable / disable strategies. (JENKINS-28298)
    • "Run as Specific User" is disabled by default. You need to enable it after upgrading from a prior version if you use it.
  • Supports workflow (JENKINS-26670)
  • Supports apitoken for authentication. (JENKINS-22470)
  • Add support for upcoming $class annotation change (JENKINS-25403)

Version 1.0.3 (Apr 14, 2014)

  • SECURITY FIX: Authentication of "Run as Specific User" is easily bypassed by REST/CLIadded (Fixed JENKINS-22469)
  • Replaced radio buttons to dropdown selecting authorization strategies (Fixed JENKINS-20786)

Version 1.0.2 (Feb 22, 2014)

  • added AuthorizeProjectStrategyDescriptor JENKINS-20812
  • Not to send the password value to test whether password is required.

Version 1.0.1 (Nov 30, 2013)

  • Fix a problem that a new user created if you authenticate with non-existent user (Fix JENKINS-20784)
  • Works with MatrixProject (Fix JENKINS-20785)

Version 1.0.0 (Nov 24, 2013)

  • Initial release.

5 Comments

  1. I must be doing something wrong or simply impossible because I can't make this plugin work as I need.Currently I'm running Jenkins 1.550 on Tomcat and have installed version 1.0.1 of this plugin.

    My objective is to let anonymous users run any job but those in need of specific authorization. I have a standard security set up (as indicated at https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup) with a couple of  users in the Jenkins own user database; and these users will be able to run the jobs needing authorization.

    For those jobs that can't be run by anonymous users I've configured the "Configure build authorization" section to indicate that they can only be run by a specific user (one from the Jenkins database). 

    But no matter what, anonymous users continue to be able to run these jobs.

    The same happens with identified users different to the one authorized in the job. They can run the buid without impediments and the job never asks for password.

    1. Authorize Project plugin is not suitable for your case.
      You should use Matrix Authorization Strategy Plugin, which is bundled with Jenkins.

      Authorize Project plugin allows ANY users to run a job AS SPECIFIED users, which allows anonymous users to run the job.
      Matrix Authorization Strategy Plugin allows ONLY SPECIFIED users to run jobs, which requires anonymous users to enter passwords.

      You may be confused with authentication and authorization.
      Requiring passwords is authentication.

  2. Help!

    We recently installed this plug-in to take advantage of the "Run as User who Triggered Build". We then setup a "test job" with the follow shell command:

    #!/bin/csh
    echo "Build: ${JOB_NAME} [${BUILD_NUMBER}]"
    echo "Workspace: ${WORKSPACE}"
    echo Linux user: $user
    echo Jenkins user: $BUILD_USER
    echo "HACK: This line will not show in Console Output"
    
    

    I was expecting that the output for $user will be my name, instead, it is still the "system id" that started Jenkins.  I was unable to get the job to be truly run as the triggered user...  Do you happen to know what I did wrong?

    I am using LDAP for authentication.

    Thanks and Regards.

    1. Authorize-project plugin controls only authorizations of Jenkins, not those of OS.
      You should call sudo command from your scripts for that purpose.

      1. Thanks...  I misunderstood the plug-in then.