BuildMaster Documentation

Security and Privileges

Users and Groups in BuildMaster

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

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

  • Built-In - The default basic user account system used by new installs of BuildMaster.
  • 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 BuildMaster for the user directory you are switching to. If you do accidentally lock yourself out, don’t worry; you can easily run the BuildMaster.Service.exe program, and select the reset to Built-In option.

Tasks

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

Creating a Task in BuildMaster

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 (production vs. all environments) always override.

For Example

Tasks may be scoped at the environment and/or application level. In the example below, Karl is a member of the DevTeam and is the only user who has the permission to deploy to the Production environment for the Accounts application. The Accounts application is likely a mission critical app and therefore the enterprise has added strict restrictions, with only Karl given the permission for deployment in the Production environment.

Permission and restrictions per User

Everyone in the Release managers group are able to Coordinate Releases and Manage application because permission are additive and the scope is set at system wide level.

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 BuildMaster

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, but are automatically purged.

An API key may be passed to an endpoint 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