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:
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.
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.
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.
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.
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 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
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:
X-ApiKey) - all content types
key) - all content types
key) - only
API_Key) on root object - only