Details

    • Type: New Feature
    • Status: Open
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: 3.3.1
    • Fix Version/s: None
    • Component/s: Security
    • Labels:
      None
    • Environment:

      RHEL 6

      Description

      In Our Company we host one Central Artifactory for all Projects. As we are a full service IT Company and no it-product company all projects are way different with different people...
      Each Project we have in our company get’s it’s own set of LOCAL repositories (usually a release repo, one snapshot repo and one 3rd-partylibs-repo for libs that are not on remot erepos.)
      These Repos get own permission targets where only special directory-groups get permission to.

      Each Project gets one or two virtual repositories containing the local repositories and the set of remote/cache repositories they need for successful builds

      Sadly the current Permission Management does not fit to this scenario because ( "+" means: good behaviour; "-" means: bad behaviour):
      + Users can only download from repositories they have permission to
      + Users can only deploy to repositories they have permission to
      + users only see local repositories they have permission to
      + users can only see remote/cache repos they have permission to

      • Users see ALL Virtual Repositories by name although they have no permission to certain local repositories that are boudn to the virtual one
      • user see ALL Builds in the Builds-Browser if they have at least one "deployer"-permission on one local/remote repository (that's worst)
      • adminsitrator must pay good attention by setting up permission target
      • adding a LDAP-Group into Artifactory is harmful (import-button etc...)

      I'd like to see a permission management system that covers our usage scenario:
      permisions for: Build Browser-View-parts (e.G. also "only license tab for certain users", permissions for virtual repos (see or not to see), NO IMPORTING of LDAP-Groups (just search them), ...

      If you like I can go more in detail but at first I like to hear your opinion if this is a case that may be implemented in future versions or what plans you have.

      Thanks,
      for us it's more ore less important: As if we want to open a certain instance for customer-access detailed permissions is needed.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                felix.herzog Felix Herzog
              • Votes:
                1 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: