Hedgehog Documentation

Security and Access Controls

  • Last Modified: 2019-07-18

Security and access control policies are defined by giving principals (users or groups) permission to perform certain tasks in a certain scope (either environment-specific, project-specific, or globally).

For example, you can say "The 'HDARS Developers' group may 'Deploy to Environment' to the 'Development environment.'"

Principals are defined in a user directory, which is either internal (i.e. built-in to Hedgehog) 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 memberships.

You can also restrict principals from performing tasks, such as "The 'Developers' group may not 'Deploy to Environment' for the 'Production' environment." These overlapping rules, as well as externally-defined user directories, can be used to model granular access control policies.


Hedgehog ships with five built-in tasks.

Administer Allows unrestricted access to all functionality within Hedgehog.
Coordinate Releases Allows release planning (but not deployment) functionality for a project.
Deploy to Environment Allows environment-specific deployment functionality within the context of a project.
Manage Project Allows full managerial and deployment access within the context of a project.
View Project Allows view access within the context of a project.

Adding Permissions and Restrictions

Tasks are assigned to principals by adding or deleting grants (permissions and restrictions) from the Admin > Security > Tasks page. Grants are comprised of the following:

  • Principal - either a user or a group
  • Scope - a specific environment, all environments, a specific project, or all projects
  • Task - what the principal may (or may not) perform

Task Resolution

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, Hedgehog uses the following guidelines to resolve tasks:

  1. More-specific grants override less-specific
  2. Restrictions override Permissions

For example, consider the following set of rules:

  1. The 'Developers' group may 'Deploy Packages'
  2. The 'Developers' group may not Deploy Packages in a 'Production' environment
  3. The 'Developers' group may Deploy Packages in the 'HDARS' project in a 'Production' environment

A more natural way to describe this in English might be:

Developers are allowed to deploy packages to any environment except Production. Unless it's the HDARS project, in which case they can deploy it to production.

In this case, the restriction (rule 2) only applies to the Production scope, and in that case, it will override the first grant (rule 1). However, the second grant (rule 3) is more specific than the restriction (rule 2), and thus is overridden.

Specific Algorithm

All of the grants that would apply to the attribute demand (e.g. view project, deploy package, etc) for the specified scope (i.e. project, environment) are gathered into a list, and then sorted by comparing each rule's scope using the following priority.

  • User
  • Project + Environment
  • Project
  • Environment
  • Environment Ancestor
  • Project
  • Project Ancestor
  • Restriction

For example, a User-specific rule will be sorted above a Project Ancestor rule. The first rule is then used; if it is a grant, then the user will be permitted to perform the requested action.

Users and Groups

A user directory is a collection of users and groups that Hedgehog can query. They are extensible (which means you can write your own), and Hedgehog ships with two directories:

  • Built-In - The default basic user account system used by new installs of Hedgehog.
  • LDAP/Single Domain - Users and groups from an LDAP directory (Active Directory) are used; this can come from multiple domains in an Active Directory forest.

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 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 Hedgehog for the user directory you are switching to. If you do accidentally lock yourself out, don’t worry; you can easily run the Hedgehog.Service.exe program, and select the reset to Built-In option.

Built-In Directory

Hedgehog's built-in user directory is used by default and initially contains a user with the username "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 our products; check out the shared documentation.

More on this topic:

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit ce197caa on master