ProGet Documentation

Security and Privileges

Users and Group add a level of granular control and security within ProGet. By associating users with a group or groups, organization are able to permit and restrict access to appropriate users.

A user directory is a collection of users and groups that ProGet can query. Currently, ProGet supports three types of user directories:

  • Built-In - The default basic user account system used by new installs of ProGet.
  • LDAP/Single Domain AD - Users and groups from an LDAP directory are used, such as an Active Directory domain.
  • AD Domain Forest - Users and groups from multiple domains in an Active Directory forest are used.

Directories are exclusive; meaning you can only use one at a time. For this reason, it’s important to make sure you will have sufficient administer permissions in ProGet for the user directory you are switching to. If you do accidentally lock yourself out, don’t worry; you can easily run the ProGet.Service.exe program, and select the reset to Built-In option.

Built In Directory

ProGet's built in user directory is used by default and initially contains two user accounts:

  • Admin - Administrator with full privileges; default password is Admin
  • Anonymous - Special user which represents anyone browsing the site anonymously


ProGet allows you to create and customizes as many tasks as needed. Tasks in ProGet define the specific ability, access, and functions users or group are allowed to edit, create, and view. ProGet comes built-in with four tasks out of the box: Administer, Manage Feed, Publish Packages, and View and Download Packages. Built-in task can be edited and modified but it’s important to note that future updates may affect these built-In tasks.

ProGet allows you to create specific tasks that can be scoped at a feed level:

Creating a Task in ProGet

Administrators can assign restrictions and permissions based on a group and individual users. It's important to note that permissions are additive and restrictions override permission when they’re at the same level; the more specific personnel (One user vs. Group) or a more defined scope (Specific Feed vs. All Feeds) always override.


By associating users with a group you're able to assign alike users the same permissions and restrictions. For example everyone in the "Managers" group has access to manage feeds except the private-npm feed, only Bob who is also part of the managers groups has the permission to manage the npm feed.

Permissions and restrictions in ProGet

API Access & API Keys

API Keys are designed to grant access to other tools and integrations. You can control which functionality a key may be used for, and delete keys that are not used.

Granting access to the Native API will effectively allow for full control of the instance

API Keys in ProGet

To assist with debugging API usage, the request/response is logged whenever an API endpoint is accessed with a key. These logs are not retained indefinitely - they are automatically purged after a period of time.

Using API Keys

An API key may be passed to any endpoint (except Feed API endpoints - see below) in one of four ways, depending on the content type of the expected request:

  • Request header (X-ApiKey) - all content types
  • Querystring value (key) - all content types
  • Form value (key) - only application/x-www-form-urlencoded content type
  • JSON property (API_Key) on root object - only application/json content type

Using Feed API Keys

Feed APIs work a little differently since they are designed to integrated seemlessly with drastically different client tools. For this reason, Feed API key authentication is performed using HTTP basic authentication. To authenticate using a Feed API key, supply "api" for the user name and the API key for the password.

If a Feed API user is specified, then the Feed API key will effectively authenticate as the specified user and have all of that user's privileges. If no Feed API user is specified, the Feed API key will have permission to perform any feed-scoped privilege.