[JIRA] [authorize-project-plugin] (JENKINS-35081) Separate authorization configuration page

21 views
Skip to first unread message

devld@ikedam.jp (JIRA)

unread,
May 23, 2016, 7:46:01 PM5/23/16
to jenkinsc...@googlegroups.com
ikedam created an issue
 
Jenkins / New Feature JENKINS-35081
Separate authorization configuration page
Issue Type: New Feature New Feature
Assignee: Unassigned
Components: authorize-project-plugin
Created: 2016/May/23 11:45 PM
Priority: Major Major
Reporter: ikedam
  • Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
  • When a plugin lists up credentials, 
    public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
    Authentication auth = Tasks.getAuthenticationOf(project);
    return new StandardUsernameListBoxModel().withEmptySelection().withAll(
        CredentialsProvider.lookupCredentials(StandardUsernameCredentials.class, auth);
}
  • Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

Issues:

  • How to control permissions to configure jobs
    • You don't want to allow other users configure jobs when you use "Run as Specific User".
  • Should the configuration file be separated ftom config.xml?
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

devld@ikedam.jp (JIRA)

unread,
May 23, 2016, 7:58:01 PM5/23/16
to jenkinsc...@googlegroups.com

> How to control permissions to configure jobs

Unfortunately, Jenkins doesn't provide a machanism to override ACLs of items.
Only AuthorizationStrategy decides ACLs

Possible solutions.

  • authorize-project provides a new AuthorizationStrategy wrapping other strategies.
    • authorize-project works only when that wrapping strategy is set to Jenkins.
  • Improve Jenkins, and add a mechanism to override ACLs by plugins.

devld@ikedam.jp (JIRA)

unread,
May 23, 2016, 8:04:01 PM5/23/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

I believe I can bind a custom configuration file to a job with TransientActionFactory.

stephenconnolly@java.net (JIRA)

unread,
May 24, 2016, 5:36:01 AM5/24/16
to jenkinsc...@googlegroups.com

Here is the interim hack to make this safe on older Jenkins instances:

Ok if you have a JobProperty that is @Extension(ordinal=Double.MAX_VALUE) then https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/Job.java#L1193 should call https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/ReconfigurableDescribable.java#L82 for that JobProperty if not first then at least very very early on in config submit.

If you have the reconfigure method throw an authorization exception then that should prevent the job from being reconfigured.

Here is the long term solution:

Add a decorator interface like ReconfigurableDescribable that allows decorating the ACL, then in Job.getACL() iterate the list of job properties (in reverse order) for instances that implement that interface and then apply the decoration. (we want to iterate in reverse order so that the highest @Extension(ordinal) wins

Hope that helps and avoids that AuthorizationStrategy hack you were thinking of.

stephenconnolly@java.net (JIRA)

unread,
May 24, 2016, 5:40:01 AM5/24/16
to jenkinsc...@googlegroups.com

For the hack you can have a AdministrativeMonitor check if the JobProperty is first and alert with the name of the plugin that won out if it isn't first saying something like "You are running Jenkins < 2.7 and the FooManchu plugin has declared a Job property of type FooManchuJobProperty with a higher priority than the AuthorizeProject plugin's job configuration protection. A user may be able to alter the configuration of the FooManchuJobProperty in cases where they should not. Please alert the maintainer of the FooManchu plugin. [DISMISS]"

stephenconnolly@java.net (JIRA)

unread,
Jun 10, 2016, 6:27:01 AM6/10/16
to jenkinsc...@googlegroups.com
stephenconnolly updated an issue
Change By: stephenconnolly
* Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
* When a plugin lists up credentials,
{code}

public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
    Authentication auth = Tasks.getAuthenticationOf(project);
    return new StandardUsernameListBoxModel()

 . withEmptySelection includeEmptyValue () .withAll(
        CredentialsProvider . lookupCredentials includeAs ( auth, project, StandardUsernameCredentials.class , auth );
}
{code}
* Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

Issues:

* How to control permissions to configure jobs
** You don't want to allow other users configure jobs when you use "Run as Specific User".
* Should the configuration file be separated ftom config.xml?

devld@ikedam.jp (JIRA)

unread,
Jul 26, 2016, 6:36:02 PM7/26/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

> Improve Jenkins, and add a mechanism to override ACLs by plugins.

I'm trying this way in JENKINS-13190 and https://github.com/jenkinsci/jenkins/pull/2481.
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

devld@ikedam.jp (JIRA)

unread,
Jul 27, 2016, 7:57:01 PM7/27/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

As stephenconnolly pointed in https://github.com/jenkinsci/jenkins/pull/2481#issuecomment-235748828 , it's not a required feature to restrict permissions to configure jobs depending on the configuration of authorize-project.

Instead, users can use the authorization strategy that can configure per-job permissions like ProjectMatrixAuthorizationStrategy or role-based-strategy plugin and restrict permissions by themselves.
Authorize-project can display warnings if one tries to configure an authorization that isn't match with permissions of the job.

devld@ikedam.jp (JIRA)

unread,
Jul 27, 2016, 8:12:04 PM7/27/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081
  • Is it still useful to provide an option to restrict permissions depending on authorize-project configurations?
    • Especially when Jenkins is not configured with an authorization strategy providing per-job permissions.
      • But it might mean administrators expect not to set per-job permissions.
  • When restricted the permission, what happens if configured a user without CONFIGURE permission? It results no one can configure the job any longer.
    • Administrators should still configure the job.
  • How to display warnings?
    • I have to display warnings only after authentication succeeds. This means it requres an intermediate page to display warnings.
      • How to hold the user inputs in the intermediate page?

Anyway, these all issues are for SpecificUsersAuthorizationStrategy.
I believe it's fundamentally unstable unsecure, and alternative feature is expected in future.

devld@ikedam.jp (JIRA)

unread,
Jul 28, 2016, 6:15:02 AM7/28/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

> Authorize-project can display warnings if one tries to configure an authorization that isn't match with permissions of the job.

I can never do this!
ACL only allows test a permission for an authorization,
and doesn't provide an interface to get authorizations that have a permission.

stephenconnolly@java.net (JIRA)

unread,
Jul 28, 2016, 7:09:03 AM7/28/16
to jenkinsc...@googlegroups.com

>> > Authorize-project can display warnings if one tries to configure an authorization that isn't match with permissions of the job.
> I can never do this!

But if one is trying to configure an authorization, ipso facto one has the authorization to try with... thus one can test the ACL with the supplied authorization and provide the warning or reject the change

devld@ikedam.jp (JIRA)

unread,
Aug 1, 2016, 5:58:04 AM8/1/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

> But if one is trying to configure an authorization, ipso facto one has the authorization to try with... thus one can test the ACL with the supplied authorization and provide the warning or reject the change

I can't get your point.
I might have failed to describe what I want.
Let's consider a case there're users A and B.
When user A is configure a job built as user A,
I want to display a warning to user A if user B can configure the job.

devld@ikedam.jp (JIRA)

unread,
Aug 1, 2016, 6:33:02 AM8/1/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

I considered this issue again, and I still believe I require one of following feature.

1. Forbid configuration by a non-admin user who isn't configured with authorize-project.
2. Display a warning message if a non-admin user who isn't configured with authorize-project can configure the job.
3. Disable authorize-project for a job if that job is configured by another user.
4. Remove SpecificUsersAuthorizationStrategy and SystemAuthorizationStrategy and introduce alternate ones.

The approach with ReconfigurableDescribable might work, but I don't like it as:

  • It requires to define needless JobProperty.
  • It is really implementation-dependent. It reminds me JENKINS-28298, a security issue caused by the change of exception handling in Jenkins core.
  • It doesn't look to work with REST and CLI.

I know these issues are also applicable to current implementations of SpecificUsersAuthorizationStrategy and SystemAuthorizationStrategy, and, therefore, I want to resolve these issues on this occasion.

"Users should configure appropriate permissions when they use authorize-project"
might be correct, but unfortunately, I don't trust that users can set up appropriate security configurations without helps, and I believe I have to provide a explicit mechanism to protect securities (at least, displaying warnings).

devld@ikedam.jp (JIRA)

unread,
Aug 1, 2016, 6:35:01 AM8/1/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

It's really strange that authorize-project is the ONLY implementation of QueueItemAuthenticator, isn't it?
Is there another implementaion in Jenkins Enterprise?

devld@ikedam.jp (JIRA)

unread,
Aug 1, 2016, 10:17:01 AM8/1/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

> 3. Disable authorize-project for a job if that job is configured by another user.

This might be achieved with ItemListener#onUpdated or SaveableListener#onChange. They should be triggered even via REST or CLI.

devld@ikedam.jp (JIRA)

unread,
Aug 2, 2016, 8:23:01 PM8/2/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

I'm rethinking whether I really need this feature.
And I think it's time to rethink the feature of `QueueItemAuthenticator` itself.

Questions in my mind

  • Why using `Authentication`?
    • It means using users avaiable in `SecurityRealm`s
      • It might make sense to introduce to authorize-project a new feature to define `Authentication` outside `SecurityRealm`s.
    • Administrators using external user directories for `SecurityRealm` can have difficulties administering authorizations for builds as authorizations for builds should be often considered like artificial persons in law.
  • "Run as SYSTEM" is useless for plugins take care of `QueueItemAuthenticaror`
    • Plugins never know they are running as SYSTEM whether for it is configured explicily or it is not configured at all (JENKINS-37047)
  • Why use build authorization during configuration?
    • Why not only display items accessible by the configuring use.
    • I suppose this means that Iassume build authorizarions are used as setuid in UNIX systems.
    • Generally speaking, setuid is considered a bad manner, isn't it?
    • It can be used in that way, but should I support those usages positively?

devld@ikedam.jp (JIRA)

unread,
Sep 15, 2016, 4:50:03 PM9/15/16
to jenkinsc...@googlegroups.com
ikedam commented on New Feature JENKINS-35081

I found I mixed up several different problems and tried to resolve them at all.
(I made those problems clear in JENKINS-38217)

I now believe those problems can be resolved one-by-one.

And it also told me that I no longer need to splitting configuration files:

  • It relates not to the original purpose of separating the configuration page but rather to JENKINS-38219 (Restrict Job.CONFIGURE permissions by plugins).
  • It doesn't work as expected until I resolve JENKINS-38219. And once after I resolve JENKINS-38219, I no longer need to split configuration files for security purposes.

stephenconnolly@java.net (JIRA)

unread,
Sep 16, 2016, 7:41:01 PM9/16/16
to jenkinsc...@googlegroups.com
stephenconnolly assigned an issue to stephenconnolly
Change By: stephenconnolly
Assignee: stephenconnolly

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:36:01 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/AuthorizationAction/index.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/authorize.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/config.jelly
http://jenkins-ci.org/commit/authorize-project-plugin/79d7bd575740aea53c0dae1f636451a08a3cac66
Log:
JENKINS-35081 Split the configuration of authentication into a separate screen

  • I still have some tests to fix up before this change is ready

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:36:02 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/resources/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer/config.jelly
http://jenkins-ci.org/commit/authorize-project-plugin/41a3f88b44e7afd861139107de7e2275a1401f9b
Log:
JENKINS-35081 Oops without this file the veto does not work

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:36:02 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
http://jenkins-ci.org/commit/authorize-project-plugin/4ebd13f03eccb0f82702e0bff4a7e13be4ff290a
Log:
JENKINS-35081 Need a @DataBoundConstructor

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:36:02 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties
http://jenkins-ci.org/commit/authorize-project-plugin/d5caebdabb4d004379a9163ade3dc65ae22b6f55
Log:
JENKINS-35081 Give a more meaningful error message

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:36:05 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
http://jenkins-ci.org/commit/authorize-project-plugin/1505f29d1c7ac6fe12918886fd2cd7cd4aa5988c
Log:
JENKINS-35081 Adding some javadocs

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:02 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/AuthorizationAction/action.jelly
http://jenkins-ci.org/commit/authorize-project-plugin/052ea591b278614ff6ee616671186acd24e1becd
Log:
JENKINS-35081 Hide the action from users that do not have the required permissions

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:02 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/c303dbdec32a2070544d992b20df67b6958f28a4
Log:
JENKINS-35081 More tests fixed

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:03 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/test/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticatorTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/dba0d59890693da379a6338248b7ce44b20ebe97
Log:
JENKINS-35081 Fix failing test

  • The test case was failing for a now invalid condition as the stronger validation fo Guice will ensure that any
    AuthorizationProjectStrategy that uses a Descriptor which is not extending AuthorizationProjectStrategyDescriptor
    will not be instantiated. For this reason I removed the parts of the test that are now invalid

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:03 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/config.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/help-noNeedReauthentication.html
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/help-noNeedReauthentication_ja.html
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/5e13d24962ebcc8dfc2067e159777ce0a75a32e0
Log:
JENKINS-35081 The reconfiguration stuff no longer makes sense with screen separation

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:03 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategyDescriptor.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java
http://jenkins-ci.org/commit/authorize-project-plugin/5664d9f32e56a96e5c7ffb3a11756ee6c32b6765
Log:
JENKINS-35081 Move the permission check to the constructor/readResolve

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:03 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/test/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticatorTest.java
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/498735c78f97843521be7e507642f61d472edb48
Log:
JENKINS-35081 Fix tests

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:04 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategyDescriptor.java


src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java

src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/AuthorizationAction/action.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/AuthorizationAction/index.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/authorize.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/config.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer/config.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/config.jelly
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/help-noNeedReauthentication.html
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy/help-noNeedReauthentication_ja.html
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy/global-security.jelly
src/test/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticatorTest.java
src/test/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticatorTest.java
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategyTest.java
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/4b8379e73e3e1eb2359636500c5be3d642bdd965
Log:
Merge pull request #26 from stephenc/jenkins-35081

JENKINS-35081 Split the configuration of authentication into a separate screen

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:07 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins


User: Stephen Connolly
Path:
src/test/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticatorTest.java

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:08 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
http://jenkins-ci.org/commit/authorize-project-plugin/7a04dbe7a2158b873e450b01e3f03ea715d82247
Log:
JENKINS-35081 Remove redundant null check

  • Thanks findbugs for finding that one

scm_issue_link@java.net (JIRA)

unread,
Dec 30, 2016, 9:37:08 PM12/30/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:

src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/AuthorizationAction/index.jelly
http://jenkins-ci.org/commit/authorize-project-plugin/d2926ccd24c4c704950366a2fce3e5801c2828ed
Log:
JENKINS-35081 Oops checking the wrong permission on this

devld@ikedam.jp (JIRA)

unread,
Dec 31, 2016, 12:26:03 AM12/31/16
to jenkinsc...@googlegroups.com
ikedam assigned an issue to ikedam
 

Preparing additional changes to release:
https://github.com/jenkinsci/authorize-project-plugin/pull/27
Change By: ikedam
Assignee: Stephen Connolly ikedam

scm_issue_link@java.net (JIRA)

unread,
Jan 25, 2017, 11:41:02 PM1/25/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:


src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategyDescriptor.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java

src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages_ja.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/Messages.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/Messages_ja.properties
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/c0aae28565e5e5e7b96c127c5399aa2b8d6b746c
Log:
JENKINS-35081 Additonal changes for #26

  • Users with ADMINISTER permission can always change configurations.
  • Rename `hasConfigurePermission` to `hasJobConfigurePermission` and introduce `hasAuthorizeConfigurePermission`.
  • Unify `readResolve` into `AuthorizeProjectStrategy`.

scm_issue_link@java.net (JIRA)

unread,
Jan 25, 2017, 11:41:03 PM1/25/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator.java
http://jenkins-ci.org/commit/authorize-project-plugin/6c1e7421fe9c874194daa093d17414f8e8b867e9
Log:
JENKINS-35081 Make `readResolve` `protected`

scm_issue_link@java.net (JIRA)

unread,
Jan 25, 2017, 11:41:04 PM1/25/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java

src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategyTest.java
http://jenkins-ci.org/commit/authorize-project-plugin/c7c59a201cf57e6d9d3c99ab542ab24b3944cb93
Log:
JENKINS-35081 Use AccessControlled for findAncestorObject. Allows bypassing permission checks only to system administrators.

scm_issue_link@java.net (JIRA)

unread,
Jan 25, 2017, 11:42:01 PM1/25/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectStrategyDescriptor.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ConfigurationPermissionEnforcer.java
src/main/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SystemAuthorizationStrategy.java
src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java
src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages_ja.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/Messages.properties
src/main/resources/org/jenkinsci/plugins/authorizeproject/strategy/Messages_ja.properties
src/test/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategyTest.java

JENKINS-35081 Additonal changes for #26

scm_issue_link@java.net (JIRA)

unread,
Feb 11, 2017, 10:04:01 PM2/11/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: ikedam
Path:

src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/SpecificUsersAuthorizationStrategy.java
http://jenkins-ci.org/commit/authorize-project-plugin/ac37f3fcff7a354e17996422dd33e7fc0cdcd3aa
Log:
JENKINS-35081 Fixed the reverted logic of doCheckPasswordRequested.

devld@ikedam.jp (JIRA)

unread,
Feb 11, 2017, 11:07:04 PM2/11/17
to jenkinsc...@googlegroups.com
ikedam closed an issue as Fixed
 

Stephen Connolly
Really sorry for having you wait for long time.
I released this change as authorize-project-1.3.0. It will be available in the update center in a day.
Change By: ikedam
Status: Open Closed
Resolution: Fixed

rene.scheibe@gmail.com (JIRA)

unread,
Aug 18, 2019, 5:03:02 AM8/18/19
to jenkinsc...@googlegroups.com
René Scheibe updated an issue
Change By: René Scheibe
* Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
* When a plugin lists up credentials,
{code :java }
public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
    Authentication auth = Tasks.getAuthenticationOf(project);
    return new StandardUsernameListBoxModel()
        .includeEmptyValue()
        .includeAs(auth, project, StandardUsernameCredentials.class);
}
{code}
* Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

Issues:
* How to control permissions to configure jobs
** You don't want to allow other users configure jobs when you use "Run as Specific User".
* Should the configuration file be separated ftom from config.xml?
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
Reply all
Reply to author
Forward
0 new messages