New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-13190] AuthorizationStrategyOverride #2481

Closed
wants to merge 5 commits into
base: master
from

Conversation

3 participants
@ikedam
Member

ikedam commented Jul 26, 2016

JENKINS-13190
Introduce new following extension points to allow plugins to override ACLs:

  • AuthorizationStrategyOverride<T>
    • Allow or deny specific permissions of specific items.
    • For security reasons, administrators need to configure them in the global security configuration page explicitly if they want to enable them.
      • I believe permissions should be allowed only when administrators explicitly want that as that can easily cause security vulnerabilities.
  • AuthorizationStrategyDenyOverride<T>
    • Deny specific permissions of specific items.
    • They are enabled when plugins with them are installed. No need to configure them explicitly.
      • I believe denying permissions doesn't cause security vulnerabilities.

Otherwise, plugins that want to provide their own additional ACL rules have to implement AuthorizationStrategy that alternates existing strategies like matrix-auth or role-strategy and it is apparently unreasonable.

This replaces #412:

  • Require explicit configurations to allow permissions.
  • Allow override permissions for specific items (e.g. a specific project)

Use case:

Outline of the change:

  • Add Jenkins#getOverriddenAuthorizationStrategy() which returns OverridingAuthorizationStrategy wrapping Jenkins#getAuthorizationStrategy().
  • OverridingAuthorizationStrategy injects overriding ACLs.
    • It enumerates AuthorizationStrategyOverride<T> and AuthorizationStrategyDenyOverride<T> where T matches required types (Jenkins, Job, Computer, and so on) and test the permission and return an overridden value if exists.
  • getACL methods like Jenkins#getACL(), Job#getACL(), Computer#getACL() and so on now calls Jenkins#getOverriddenAuthorizationStrategy().

Known issues and notes:

  • Overriding permissions doesn't take effects for plugins using AuthorizationStrategy#getACL(...) directly.
    • Plugins should use methods like AbstractItem#getACL() instead (I updated javadocs to describe so).
    • As far as I checked roughly, following plugins look use AuthorizationStrategy#getACL(...):
      • gitlab-auth-plugin
      • pubsub-light-module
      • support-core-plugin
  • I worry that this might performance issues as it uses Java reflections to list and filter registered instances of AuthorizationStrategyOverride.
    • Is there appropriate way to cache the results? I'm not sure when to invalidate the caches.
  • T of AuthorizationStrategyOverride<T> should be Jenkins, Job, AbstractItem, Computer, User, Cloud, Node and their supertypes.
    • More specific types, e.g. FreeStyleProject isn't applicable.
    • This is a limitation to take advantage of Java generics and have it easy for developers implement sub classes of AuthorizationStrategyOverride.
    • Please let me know if there're better ways for Java generics.

A screenshot of the Configure Global Secury page:

authorizationstrategyoverride

Show outdated Hide outdated core/src/main/java/hudson/security/AuthorizationStrategy.java
* but should not call this method directly,
* and should call {@link Node#getACL()} instead.
*
* @param node

This comment has been minimized.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

🐜 undefined Javadoc entries. Javadoc linter will argue about that

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

🐜 undefined Javadoc entries. Javadoc linter will argue about that

This comment has been minimized.

@ikedam

ikedam Jul 27, 2016

Member

Oops.
Added a commit to complete param and return of javadocs for getACLs.

@ikedam

ikedam Jul 27, 2016

Member

Oops.
Added a commit to complete param and return of javadocs for getACLs.

* @since TODO
*/
@Nonnull
public AuthorizationStrategy getOverriddenAuthorizationStrategy() {

This comment has been minimized.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

It causes a serious mess in APIs, because many plugins may still use getAuthorizationStrategy(). IMHO overriding should be done in the existing getAuthorizationStrategy() method

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

It causes a serious mess in APIs, because many plugins may still use getAuthorizationStrategy(). IMHO overriding should be done in the existing getAuthorizationStrategy() method

This comment has been minimized.

@ikedam

ikedam Jul 27, 2016

Member

I tried that approach first and found that it breaks many plugins.
Plugins with implementations for AuthorizationStrategy often contains following codes:

if (Jenkins.getInstance().getAuthorizationStrategy() instanceof ItsOwnAuthorizationStrategy) {
    String configuredField = (ItsOwnAuthorizationStrategy(Jenkins.getInstance().getAuthorizationStrategy()).getSomeField();
    // codes using its configured fields...
}

Modifying the value from getAuthorizationStrategy() breaks those plugins.
e.g. ProjectMatrixAuthorizationStrategy no longer displays AuthorizationMatrixProperty in job configuration pages.

And I decided not to modify existing getAuthorizationStrategy().

@ikedam

ikedam Jul 27, 2016

Member

I tried that approach first and found that it breaks many plugins.
Plugins with implementations for AuthorizationStrategy often contains following codes:

if (Jenkins.getInstance().getAuthorizationStrategy() instanceof ItsOwnAuthorizationStrategy) {
    String configuredField = (ItsOwnAuthorizationStrategy(Jenkins.getInstance().getAuthorizationStrategy()).getSomeField();
    // codes using its configured fields...
}

Modifying the value from getAuthorizationStrategy() breaks those plugins.
e.g. ProjectMatrixAuthorizationStrategy no longer displays AuthorizationMatrixProperty in job configuration pages.

And I decided not to modify existing getAuthorizationStrategy().

*/
@Nonnull
public AuthorizationStrategy getOverriddenAuthorizationStrategy() {
return new OverriddenAuthorizationStrategy(

This comment has been minimized.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

🐛 So it causes creation of new objects every time we check we check permissions for whatever reason. I'm afraid it's going to hammer the performance

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

🐛 So it causes creation of new objects every time we check we check permissions for whatever reason. I'm afraid it's going to hammer the performance

private <T> ACL overrideACL(@Nonnull final ACL baseAcl, @Nonnull final T item, @Nonnull final Class<T> klazz) {
return new ACL() {
@Override
public boolean hasPermission(@Nonnull Authentication a, @Nonnull Permission p) {

This comment has been minimized.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

So now we go through complex logic every time we check permissions

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

So now we go through complex logic every time we check permissions

This comment has been minimized.

@ikedam

ikedam Jul 27, 2016

Member

This may reduce the performance issue:

  final List<> overrides = AuthorizationStrategyOverrideConfiguration.enables(klazz);
  if (overrides.isEmpty()) {
    return baseAcl;
  }
  return new ACL() {
    ...
      for (AuthorizationStrategyOverrideBase d: overrides) {
        ...
      }
    ...
  }
}
@ikedam

ikedam Jul 27, 2016

Member

This may reduce the performance issue:

  final List<> overrides = AuthorizationStrategyOverrideConfiguration.enables(klazz);
  if (overrides.isEmpty()) {
    return baseAcl;
  }
  return new ACL() {
    ...
      for (AuthorizationStrategyOverrideBase d: overrides) {
        ...
      }
    ...
  }
}
* {@inheritDoc}
*/
@Override
public @Nonnull ACL getACL(@Nonnull Node node) {

This comment has been minimized.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

This approach is pretty unreliable. If somebody creates new getACL() methods in Auth strategy, he should ensure that these methods get overridden in this class.

@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

This approach is pretty unreliable. If somebody creates new getACL() methods in Auth strategy, he should ensure that these methods get overridden in this class.

/*
* The MIT License
*
* Copyright (c) 2011, CloudBees, Inc.

This comment has been minimized.

@oleg-nenashev
@oleg-nenashev

This comment has been minimized.

@ikedam

ikedam Jul 27, 2016

Member

This is an almost copy of
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/security/QueueItemAuthenticatorConfiguration/config.groovy

I'm not sure how to do for the license notice when I copied an existing file.

@ikedam

ikedam Jul 27, 2016

Member

This is an almost copy of
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/security/QueueItemAuthenticatorConfiguration/config.groovy

I'm not sure how to do for the license notice when I copied an existing file.

@oleg-nenashev

This comment has been minimized.

Show comment
Hide comment
@oleg-nenashev

oleg-nenashev Jul 27, 2016

Member

I'm very aware about performance impact of such approach. Even if there is no extension points added, there is some logic like extension point retrieval and overriding of Strategies in each permission check. IMHO all this logic should be launched if and only if there is an extension point implementation.

Member

oleg-nenashev commented Jul 27, 2016

I'm very aware about performance impact of such approach. Even if there is no extension points added, there is some logic like extension point retrieval and overriding of Strategies in each permission check. IMHO all this logic should be launched if and only if there is an extension point implementation.

@stephenc

This comment has been minimized.

Show comment
Hide comment
@stephenc

stephenc Jul 27, 2016

Member

I am unclear why you need this for JENKINS-35081

Member

stephenc commented Jul 27, 2016

I am unclear why you need this for JENKINS-35081

@ikedam

This comment has been minimized.

Show comment
Hide comment
@ikedam

ikedam Jul 27, 2016

Member

Moving OverridingAuthorizationStrategy#overrideStrategy to Jenkins and calling it from Job#getACL(), Computer#getACL() and so on would resolves problems pointed in following comments.

Let me know that's a correct approach.

Member

ikedam commented Jul 27, 2016

Moving OverridingAuthorizationStrategy#overrideStrategy to Jenkins and calling it from Job#getACL(), Computer#getACL() and so on would resolves problems pointed in following comments.

Let me know that's a correct approach.

@ikedam

This comment has been minimized.

Show comment
Hide comment
@ikedam

ikedam Jul 27, 2016

Member

I am unclear why you need this for JENKINS-35081

I think following 4 ways for JENKINS-35081

  • A. Override ACL to deny Job.CONFIGURE for jobs with authorize-project configured
    • A-1. Add a new feature to Jenkins to override ACLs by plugins (this request)
    • A-2. Provides an implementation of AuthoziationStrategy that wraps another strategy.
  • B. Raise an error when a user not configured with authorize-project opens a job configuration page.
  • C. Raise an error when a user not configured with authorize-project submits a job configuration page.

I prefer them in the order of A-1, B and C.
B and C looks unstable to me. (On the other hand, I agree that SpecificUserAuthorizationStrategy in authorize-project already does something like that)

I hope this clarifies why I want this feature for JENKINS-35081.

Member

ikedam commented Jul 27, 2016

I am unclear why you need this for JENKINS-35081

I think following 4 ways for JENKINS-35081

  • A. Override ACL to deny Job.CONFIGURE for jobs with authorize-project configured
    • A-1. Add a new feature to Jenkins to override ACLs by plugins (this request)
    • A-2. Provides an implementation of AuthoziationStrategy that wraps another strategy.
  • B. Raise an error when a user not configured with authorize-project opens a job configuration page.
  • C. Raise an error when a user not configured with authorize-project submits a job configuration page.

I prefer them in the order of A-1, B and C.
B and C looks unstable to me. (On the other hand, I agree that SpecificUserAuthorizationStrategy in authorize-project already does something like that)

I hope this clarifies why I want this feature for JENKINS-35081.

@stephenc

This comment has been minimized.

Show comment
Hide comment
@stephenc

stephenc Jul 27, 2016

Member

I think following 4 ways for JENKINS-35081

A. Override ACL to deny Job.CONFIGURE for jobs with authorize-project configured
A-1. Add a new feature to Jenkins to override ACLs by plugins (this request)
A-2. Provides an implementation of AuthoziationStrategy that wraps another strategy.
A-2 would fail in the way I explained in #2481 (comment)
B. Raise an error when a user not configured with authorize-project opens a job configuration page.
C. Raise an error when a user not configured with authorize-project submits a job configuration page.
I prefer them in the order of A-1, B and C.
B and C looks unstable to me. (On the other hand, I agree that SpecificUserAuthorizationStrategy in authorize-project already does something like that)

I hope this clarifies why I want this feature for JENKINS-35081.

Actually it doesn't clarify at all to me.

In my view of JENKINS-35081 you just add a new Action to jobs for called Authentication

So currently the Action menu looks like

screen shot 2016-07-27 at 23 57 48

With JENKINS-35081 you just move the configuration of the authorization from the job's Configure screen to this other screen. (You can store the authorization in a side file and use a reconfigurable property so that config.xml POSTs etc will not.)

So we have something like

screen shot 2016-07-27 at 23 59 41

Now it is not the authorize project plugin's responsibility to start tweaking the job configuration permissions. The system administrator should use their authorization strategy to lock the job down if they want the job locked down.

Admins grant EXTENDED_READ to users that are allowed to view a jobs configuration. You should not be stopping that.

Admins grant CONFIGURE to users that are allowed to configure jobs. You should not be stopping that.

The authorize project plugin should stick to a single responsibility principle.

Having said all that, I am not against JENKINS-13190, I just completely fail to see how it is blocking or necessary in any way to implement JENKINS-35081 (which should be just adding a new action and moving the configuration so that anyone viewing the job configuration will be able to have credentials drop-downs respect the authentication that the job will run as)

But once we remove the driver of JENKINS-35081 then I think we can probably approach JENKINS-13190 the right way... and then if we have a JENKINS-13190 implementation there could be an additional helper plugin that would use an implementation of JENKINS-13190 to layer on restrictions on the ACLs of projects under specific conditions - one of which could be enabling authorize project plugin being enabled for that job

I hope this clarifies what my query is

Member

stephenc commented Jul 27, 2016

I think following 4 ways for JENKINS-35081

A. Override ACL to deny Job.CONFIGURE for jobs with authorize-project configured
A-1. Add a new feature to Jenkins to override ACLs by plugins (this request)
A-2. Provides an implementation of AuthoziationStrategy that wraps another strategy.
A-2 would fail in the way I explained in #2481 (comment)
B. Raise an error when a user not configured with authorize-project opens a job configuration page.
C. Raise an error when a user not configured with authorize-project submits a job configuration page.
I prefer them in the order of A-1, B and C.
B and C looks unstable to me. (On the other hand, I agree that SpecificUserAuthorizationStrategy in authorize-project already does something like that)

I hope this clarifies why I want this feature for JENKINS-35081.

Actually it doesn't clarify at all to me.

In my view of JENKINS-35081 you just add a new Action to jobs for called Authentication

So currently the Action menu looks like

screen shot 2016-07-27 at 23 57 48

With JENKINS-35081 you just move the configuration of the authorization from the job's Configure screen to this other screen. (You can store the authorization in a side file and use a reconfigurable property so that config.xml POSTs etc will not.)

So we have something like

screen shot 2016-07-27 at 23 59 41

Now it is not the authorize project plugin's responsibility to start tweaking the job configuration permissions. The system administrator should use their authorization strategy to lock the job down if they want the job locked down.

Admins grant EXTENDED_READ to users that are allowed to view a jobs configuration. You should not be stopping that.

Admins grant CONFIGURE to users that are allowed to configure jobs. You should not be stopping that.

The authorize project plugin should stick to a single responsibility principle.

Having said all that, I am not against JENKINS-13190, I just completely fail to see how it is blocking or necessary in any way to implement JENKINS-35081 (which should be just adding a new action and moving the configuration so that anyone viewing the job configuration will be able to have credentials drop-downs respect the authentication that the job will run as)

But once we remove the driver of JENKINS-35081 then I think we can probably approach JENKINS-13190 the right way... and then if we have a JENKINS-13190 implementation there could be an additional helper plugin that would use an implementation of JENKINS-13190 to layer on restrictions on the ACLs of projects under specific conditions - one of which could be enabling authorize project plugin being enabled for that job

I hope this clarifies what my query is

@ikedam

This comment has been minimized.

Show comment
Hide comment
@ikedam

ikedam Jul 27, 2016

Member

@stephenc
I got your point.

I plan to provide an alternate feature for "No need for re-authentication" of SpecificUsersAuthorizationStrategy.
Though, I agree it's not mandatory and I can provide a behavior like displaying warnings "Job can be configured by users who aren't authorized for builds" instead.

On the other hand, I still think that it's useful to provide an option to restrict CONFIGURE (or may be EXTENDED_READ) only to a user configured with authorize-project.
Let me have more time to consider that.

Member

ikedam commented Jul 27, 2016

@stephenc
I got your point.

I plan to provide an alternate feature for "No need for re-authentication" of SpecificUsersAuthorizationStrategy.
Though, I agree it's not mandatory and I can provide a behavior like displaying warnings "Job can be configured by users who aren't authorized for builds" instead.

On the other hand, I still think that it's useful to provide an option to restrict CONFIGURE (or may be EXTENDED_READ) only to a user configured with authorize-project.
Let me have more time to consider that.

@stephenc

This comment has been minimized.

Show comment
Hide comment
@stephenc

stephenc Jul 28, 2016

Member

@ikedam I view the concern you have as being defects in the Authorization Strategy implementations.

Having had a decent Authorization Strategy since 2011 (RBAC) which allows filtering out roles and adding them back in easily, there would be no requirement for these changes.

But more importantly, from our experience with the RBAC strategy, it is critical to provide a way for at least admins to see what the effective permissions are on any item where the permissions can be changed. This is why in the RBAC strategy we provide the Roles summary:

view-roles-initial

So an additional issue I see with this proposed change is that it does not include a mechanism for at least administrators to figure out what is going on in a consistent way.

I guess what I am leaning towards is that we probably need to enhance the AuthorizationStrategy API to include an extension point for explaining effective permissions if we are going to start adding layers of permission modifications, and as such I suspect I am 👎 on this change in the absence of such a mechanism... at least on the basis of the experience we had that resulted in our having to add such explanation features to our RBAC strategy.

(note that the mechanism can be a hidden action much like the /whoAmI action currently in Jenkins... in fact for RBAC we have our own hidden actions .../roles/whoAmI which allows any user to at least discover what RBAC is inferring about the RBAC group membership on any item... but if core exposed an extension point for Authorization Strategies to provide their own explanations that would be much better and we could redirect the .../roles/whoAmI actions to the "official" ones)

Member

stephenc commented Jul 28, 2016

@ikedam I view the concern you have as being defects in the Authorization Strategy implementations.

Having had a decent Authorization Strategy since 2011 (RBAC) which allows filtering out roles and adding them back in easily, there would be no requirement for these changes.

But more importantly, from our experience with the RBAC strategy, it is critical to provide a way for at least admins to see what the effective permissions are on any item where the permissions can be changed. This is why in the RBAC strategy we provide the Roles summary:

view-roles-initial

So an additional issue I see with this proposed change is that it does not include a mechanism for at least administrators to figure out what is going on in a consistent way.

I guess what I am leaning towards is that we probably need to enhance the AuthorizationStrategy API to include an extension point for explaining effective permissions if we are going to start adding layers of permission modifications, and as such I suspect I am 👎 on this change in the absence of such a mechanism... at least on the basis of the experience we had that resulted in our having to add such explanation features to our RBAC strategy.

(note that the mechanism can be a hidden action much like the /whoAmI action currently in Jenkins... in fact for RBAC we have our own hidden actions .../roles/whoAmI which allows any user to at least discover what RBAC is inferring about the RBAC group membership on any item... but if core exposed an extension point for Authorization Strategies to provide their own explanations that would be much better and we could redirect the .../roles/whoAmI actions to the "official" ones)

@ikedam

This comment has been minimized.

Show comment
Hide comment
@ikedam

ikedam Jul 29, 2016

Member

@stephenc It's strange that I'm requested to do something for a plugin in Jenkins Enterprise, isn't it? It's a business of Cloudbee.

Though, I think I could get what you point.
The root cause looks to me that current features for authorization provided by Jenkins core is too poor to be used in enterprise systems. e.g.

  • ACL only provides a way to test a permission for an authentication. It cannot be viewed as a list (even though it's named Access Control List!)
  • ACL only returns a boolean value and doesn't return how it's evaluated.
  • Many implementations creates an instance of ACL everytime when it's required.

They cause difficulties of administration and performance of Jenkins.

And they are actually the points where I had difficulties to implement this change. ACL is too simple and I had few options to extend it.
I think this request is a natural extension for the current ACL features.
But this request should be reformed if ACL provides more features resolving above issues (I believe performance issues in this request would be resolved in a natural way).
Though I can provide features resolving above issues for ACLs created by AuthorizationStrategyOverride, it would be better to improve ACL itself first.

I think above issues can be resolved in following ways:

  • Create a subclass of ACL like MoreDescribableACL.
    • It provides a list of (Permission, Authentication, description).
    • This instance is expected to be used statically. (Not instantiated everytime)
    • Though I don't know the implementation of RBAC, I suppose it has an internal implementation like this. I hope that is feeded back to Jenkins core.
    • This may provide a way to inject permissions by plugins (replaces this request).
  • Migrate plugins providing AuthorizationStrategy to use MoreDescribableACL.
    • There should be plugins that cannot migrate to MoreDescribableACL especially those that retrive ACLs from external systems e.g. LDAP.

Let me know how do you think this idea.
And I suppose this should be already discussed in a JIRA ticket or included in the roadmap of Jenkins2. Please lead me if there's a such ticket.

Member

ikedam commented Jul 29, 2016

@stephenc It's strange that I'm requested to do something for a plugin in Jenkins Enterprise, isn't it? It's a business of Cloudbee.

Though, I think I could get what you point.
The root cause looks to me that current features for authorization provided by Jenkins core is too poor to be used in enterprise systems. e.g.

  • ACL only provides a way to test a permission for an authentication. It cannot be viewed as a list (even though it's named Access Control List!)
  • ACL only returns a boolean value and doesn't return how it's evaluated.
  • Many implementations creates an instance of ACL everytime when it's required.

They cause difficulties of administration and performance of Jenkins.

And they are actually the points where I had difficulties to implement this change. ACL is too simple and I had few options to extend it.
I think this request is a natural extension for the current ACL features.
But this request should be reformed if ACL provides more features resolving above issues (I believe performance issues in this request would be resolved in a natural way).
Though I can provide features resolving above issues for ACLs created by AuthorizationStrategyOverride, it would be better to improve ACL itself first.

I think above issues can be resolved in following ways:

  • Create a subclass of ACL like MoreDescribableACL.
    • It provides a list of (Permission, Authentication, description).
    • This instance is expected to be used statically. (Not instantiated everytime)
    • Though I don't know the implementation of RBAC, I suppose it has an internal implementation like this. I hope that is feeded back to Jenkins core.
    • This may provide a way to inject permissions by plugins (replaces this request).
  • Migrate plugins providing AuthorizationStrategy to use MoreDescribableACL.
    • There should be plugins that cannot migrate to MoreDescribableACL especially those that retrive ACLs from external systems e.g. LDAP.

Let me know how do you think this idea.
And I suppose this should be already discussed in a JIRA ticket or included in the roadmap of Jenkins2. Please lead me if there's a such ticket.

@stephenc

This comment has been minimized.

Show comment
Hide comment
@stephenc

stephenc Jul 29, 2016

Member

Well actually I was going to implement the config screen stuff if you indicated that you were in agreement with the idea

I suspect the OSS role strategy plugin could be made to give same, but as I don't use it, I cannot speak to that.

Also, as I said, I am not against fixing ACL, I just do not see it blocking separation of job authorisation config from main config so that everyone can actually have credentials selection that reflects the permissions that the job runs as.

HTH

Member

stephenc commented Jul 29, 2016

Well actually I was going to implement the config screen stuff if you indicated that you were in agreement with the idea

I suspect the OSS role strategy plugin could be made to give same, but as I don't use it, I cannot speak to that.

Also, as I said, I am not against fixing ACL, I just do not see it blocking separation of job authorisation config from main config so that everyone can actually have credentials selection that reflects the permissions that the job runs as.

HTH

@oleg-nenashev

This comment has been minimized.

Show comment
Hide comment
@oleg-nenashev

oleg-nenashev Jul 29, 2016

Member

Role Strategy does not support this feature right now. Long story.

For OSS there is a semi-implemented plugin here: https://github.com/ksenia-nenasheva/security-inspector-plugin (not ready for production). CC @ksenia-nenasheva. Maybe needs finalization.

I'm not sure we want to have permission visualization engine inside the core

Member

oleg-nenashev commented Jul 29, 2016

Role Strategy does not support this feature right now. Long story.

For OSS there is a semi-implemented plugin here: https://github.com/ksenia-nenasheva/security-inspector-plugin (not ready for production). CC @ksenia-nenasheva. Maybe needs finalization.

I'm not sure we want to have permission visualization engine inside the core

@ikedam

This comment has been minimized.

Show comment
Hide comment
@ikedam

ikedam Aug 1, 2016

Member

I thought over JENKINS-13190 again, and I still believe I need a feature for plugins to block configuration by unexpected users.
But now I believe I should introduce that feature in the minimum way.

  • Only for Jobs.
  • Only for Item.CONFIGURE permission.
  • Rule based (e.g. deny users non-administrative and not user A)

I'll reform the feature and recreate the pull request.

Thanks for all the review.

Member

ikedam commented Aug 1, 2016

I thought over JENKINS-13190 again, and I still believe I need a feature for plugins to block configuration by unexpected users.
But now I believe I should introduce that feature in the minimum way.

  • Only for Jobs.
  • Only for Item.CONFIGURE permission.
  • Rule based (e.g. deny users non-administrative and not user A)

I'll reform the feature and recreate the pull request.

Thanks for all the review.

@ikedam ikedam closed this Aug 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment