- 24 Sep 2021
- 4 Minutes to read
Security and Access Controls
- Updated on 24 Sep 2021
- 4 Minutes to read
Security and access control policies are defined by giving principals (users or groups) permission to perform certain tasks in a certain scope (feed-specific, feed group-specific, or globally).
For example, you can say "The 'HDARS Developers' group may 'Publish Packages' to the 'Dev' feed group", which would allow any users of that group to be able to publish packages to any of of the Dev feeds.
Scoping is only available in paid and trial ProGet editions; feed groups are available starting in ProGet v6.
Principals are defined in a user directory, which is either internal (i.e. built-in to ProGet) or external (such as Active Directory and LDAP). This allows you to create a single sign-on experience while letting other members of the organization manage user accounts and group membership.
You can also restrict principals from performing tasks, such as "The 'Developers' group may not 'Publish Packages' to the 'Restricted' feed." These overlapping rules, as well as externally-defined user directory, can be used to model granular access control policies.
ProGet ships with five tasks:
|Administer||Full control over the ProGet instance|
|Manage Feed||Allows access to manage feed settings, delete packages, and overwrite packages.|
|Promote Packages||Allows access to promote packages to a specified feed of the same feed type. Users granted this task should also be granted at least the View & Download Packages task for the source feed.|
|Publish Packages||Allows access to publish, upload, push, and pull packages from a feed.|
|View & Download Packages||Allows access to view and download packages from a feed.|
Adding Permissions and Restrictions
Tasks are assigned to principals by adding or deleting grants (permissions or restrictions) from the Admin > Security > Tasks page. Grants are comprised of the following:
- Principal – either a user or group
- Scope – a specific feed, feed group, or all feeds
- Task – what the principal may (or may not) perform
Because you can define both permissions and restrictions at multiple scoping levels, determining whether a user can perform a particular action can be quite complex. Generally speaking, ProGet uses the following guidelines to resolve tasks:
- More-specific grants override less-specific
- Restrictions override Permissions
For example, consider the following set of rules:
- The 'Developers' group may 'Promote Packages'
- The 'Developers' group may not Promote Packages to a 'Production' feed
A more natural way to describe this in English might be:
Developers are allowed to promote packages from any feed except Production.
In this case, the restriction (rule 2) only applies to the Production feed, and in that case, it will override the first grant (rule 1).
All of the grants that would apply to the attribute demand (e.g. view project, deploy package, etc.) for the specified scope (i.e. specific feed or all feeds) are gathered into a list, and then sorted by comparing each rule's scope using the following priority.
- Feed & Feed Group
For example, a User-specific rule will be sorted above a Feed-specific rule. The first rule is then used; if it is a grant, then the user will be permitted to perform the requested action.
A user directory is a collection of users and groups that ProGet can query. They are extensible (which means you can write your own), and ProGet ships with two directories:
- Built-In - The default basic user account system used by new installs of ProGet
- Active Directory (LDAP) - Users and groups from an LDAP directory (Active Directory) are used; this can come from multiple domains in an Active Directory forest.
- Hybrid - Combine multiple directories into one.
Task permissions and restrictions are associated with a user directory, which means that "bob-smith" from the Built-in directory will not necessarily have the same permissions as "bob-smith" from the Active Directory.
Directories are also 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. To combine more than one directory together, see the Hybrid User Directories information.
Built In Directory
ProGet's built-in user directory is used by default and initially contains a single user with the username "Admin" and the password "Admin". You can add additional users and groups to this directory from the Admin > Security > Users page.
Active Directory LDAP
This is common to all of our products; check out the shared documentation.
Virtual Privilege Assignments
As of ProGet v5.2.5, privileges may be granted or restricted to the following "catch-all" principals in any user directory:
- Everyone - all users with network access to the system, regardless if they are authenticated or not
- Authenticated - all users who have supplied valid login credentials
- Anonymous - all unauthenticated users with network access to the sytem (i.e. have not logged in)
Hybrid User Directories
As of ProGet v5.2.6, a hybrid user directory may be used to combine multiple user directories together, resolving principals from one or more existing user directories. This allows ProGet administrators to configure the system such that, for example, user accounts can be defined in ProGet with a fallback to Active Directory.
Visit the Hybrid User Directories documentation for more information.