Creating and Customizing Tasks
  • 16 Oct 2021
  • 5 Minutes to read
  • Dark
  • PDF

Creating and Customizing Tasks

  • Dark
  • PDF

ProGet's built-in security tasks are a good starting point, but as you expand ProGet within your organization, you may want to customize tasks to help model governance and compliance policies.

To customize the tasks available in ProGet, navigate to Admin > Users & Tasks > Tasks, and click [Customize Tasks]. From there, you can add, edit, and delete tasks.

What is Task in ProGet?

A task has a Name, Description, and a number of Security Attributes.

Built-in Tasks

You can modify ProGet's built-in tasks. However, future updates may change your description or add additional attributes as features are added; so, as always, make sure to read the upgrade notes before upgrading. ProGet uses the task's Name to determine if it's a built-in task or not.

Security Attributes

Security Attributes determine what will happen when the tasks is used in a permission or restriction.

Some attributes are considered "feed-scopable", which means they can be applied to specific feeds. Other attributes can only be applied to the system scope. For example, scheduled jobs are managed at the system level (and are used by all feeds), the "Scheduled Jobs" attribute cannot be scoped to a single feed.

If a task has only feed-scopeable tasks, then the task may be used in a Feed-specific permission or restriction.

Attribute Reference

Some of the attributes are denoted with a superscript F, which indicates that they are scopable by feed.

Administration: Configure ProGet

This is a proxy attribute for all other attributes, and should be only included in tasks that are granted to system administrators.

This task is a sort of "administrative catch all" that is used to secure pages in the administration section not covered by other attributes, including security, extensions, and all settings.

Administration: Manage ConnectorsF

When a connector is shared by multiple feeds, a user needs permission to only one of those feeds to edit the connector.

This allows users to create, edit, and delete connectors. When used in a feed-scope, connectors may only be added, edited, and deleted from permitted feeds.

Administration: Manage FeedsF

This allows for full control over the feed, including changing package stores. It is effectively administrative access for the feed, and is a proxy attribute for all other attributes.

Administration: Manage Scheduled Tasks

Manage will allow users to manually execute, and also deactivate and change the status of these jobs.

Administration: View Scheduled Tasks

View will allow users to see the result of scheduled jobs. These don't necessarily have sensitive information, but they might.

Licenses: Manage Licenses

Allows users to create, edit, and delete known license types, as well as define licensing rules on feeds and globally. This is not feed-specific by design; many packages do not use standard SPDX codes, but instead specify a custom URL (often, to their project site or source repository), and it would be practically unusable to not be permitted to define new known license types, or to make known license types a feed-specific setting.

Credentials: Manage Credentials & View Passwords

ProGet only uses Credentials for advanced Active Directory configuration.

Unless we expand Credentials to other aspects of ProGet, they will likely be removed in a future version of ProGet, and replaced with "Configure ProGet".

Vulnerabilities: Assess

Allows users to create, edit, and delete assessment types, as well as asses vulnerabilities.

Feeds: Accept Package PromotionsF

This attribute permits promoting a package from another feed (the "source" feed) into the feed this permission applies to. You should also grant View and Download Package permissions on the source feed.

Feeds: Add Package F

The Add attribute allows for UI- and API-based adding of packages.

Feeds: Delete Package F

The Delete attribute allows for UI- and API-based deleting of packages.

Feeds: Download Package F

The Download attribute allows for UI- and API-based downloading of packages. This attribute is essentially required for read-only access to a feed. There are some very limited use cases for allowing viewing feed and package metadata, but not allowing packages themselves to be downloaded (or vice versa).

Feeds: Overwrite Package F

The Overwrite attribute allows for UI- and API-based overwriting of existing packages.

Feeds: Pull Package F

The Pull attribute only allows for using the UI's "pull package" function. Granting only Pull may be useful for building a sort of approval workflow for connector packages.

Feeds: Unlist Package F

The Unlist attribute allows for UI- unlisting of packages from the Feed and the API.

Feeds: View Package F

The View attribute allows for UI- and API-based viewing of packages. This attribute is essentially required for read-only access to a feed. There are some very limited use cases for allowing viewing feed and package metadata, but not allowing packages themselves to be downloaded (or vice versa).

Task Best Practices

The granular nature of ProGet's security attributes may yield to undesired results, including giving users permissions that you don't want. When creating or customizing tasks, there are two important concepts to keep in mind: Permission by Proxy and Nonsensical Access.

Permission by Proxy

Granting someone "permission by proxy" allows them to perform a potentially undesired action using an indirect or roundabout manner.

For example, if you were to create a task that included only the "Add Package" and "Delete Package" attributes (but not the "Overwrite Package" attribute), then users with that task could indirectly overwrite packages. They'd just have to delete the package first, then add it again.

Another example is the "Configure ProGet" attribute. Users with that permission can change their own permissions, which means they can effectively do anything in ProGet they want. It just takes a few steps.

This isn't necessarily a bad practice. If you're worried that users will accidently perform actions (like overwriting packages), then this restriction may prevent that from happening. It's not good for security, however.

Nonsensical Access

Granting someone "nonsensical access" means that they can perform sensitive actions (like editing or deleting), but are restricted from less-sensitive actions (like viewing).

For example, if a task only had "Manage Feed" but not "View Feed", and a user was only granted permission to perform that task, the behavior in ProGet would be very strange. They could technically view the feed on the "manage" pages, but they'd likely get errors on the "view-only" pages.

Tasks with "nonsensical access" aren't necessarily bad, either. You may wish to use tasks to create multiple, overlapping restrictions and permissions across multiple overlapping groups.

Was this article helpful?