Skip to main content

Approval Workflows

A powerful feature of Workshop is the ability to delegate approvals decisions across your organization when running in Lockdown mode. When a user successfully completes an approval workflow they will receive allow rules for that specific application on their machine(s). This allows users to stay in Lockdown mode while still only running approved software.

Conditions for an Approval Workflow to Begin​

  • Santa has blocked an application from running on a user's system
  • The user is running in Lockdown mode and does not have an explicit rule allowing it
  • The user is part of a tag that has approval workflows configured
  • The binary or bundle have not been flagged as malware or confirmed as malware
  • If the Risk Engine is enabled then all configured plugins must return an allow decision

Risk Engine​

When the Risk Engine is configured and enabled, it will act as a gating function before it will let a user start an approval workflow. This allows admin users to set a threshhold for how risky something is and decide if admins want to let users approve for themselves or should seek expert assistance.

Flagging an Application​

During an approval workflows each user and approver is presented with the option to flag an application as malicious via a button. This allows users to report malware that could otherwise be missed by the Risk Engine plugins or applications that are potentially troublesome.

If they do flag an application as potentially malicious then all approvals workflows for that application are halted. Only after an admin has restored the state of the binary via the blockables page or APIs will approvals continue.

Auditing​

All approval workflows create audit events showing the rules that were created and the target for those rules, and which approver approved, and at which time approval was granted.

Audit Events​

All Audit Events can be seen here.

  • BLOCKABLE_FLAGGED_MALICIOUS

If a user or an approver flags a Binary or Application Bundle (aka Blockable) as malicious this event is created.

  • VOTE_CAST

When a user in a self-service or a social voting has voted to approve their software. This contains the voting user.

  • SELF_SERVICE_RULE_CREATION

This audit event is created when a user has approved their own software and a rule was created for their machines.

  • SOCIAL_VOTING_RULE_CREATION

This audit event is created when a user is in a social voting approval workflow and one of the threshholds has been met or exceeded.

  • DESIGNATED_APPROVER_REQUEST

This is created when a user is in a designated approver workflow and has asked for an application.

  • DESIGNATED_APPROVER_REQUEST_APPROVED

This is created when an approver approves a designated approver request for an application.

  • DESIGNATED_APPROVER_REQUEST_REJECTED

This is created when an approver rejects a designated approver request for an application.

  • DESIGNATED_APPROVER_RULE_CREATION

This is created when an approver approves a designated approver request for an application and rules are created.

Supported Approval Workflows​

Self-Service Approval​

The simplest approval workflow is self-service approval. This allows any user in a tag to approve their own software provided it meets all of the conditions for starting an approval workflow.

Designated Approver Workflows​

The designated approver workflows allow specific users to act as the approvers for users in a given tag. Approvers need not be admins themselves.

Manager Approval​

When configured to use manager approval. A user's manager must approve before rules are created for that user. If they approve.

A user's manager is determined based on their directory sync attributes or via the API. A user's manager can also be seen in the Settings page in the users section at the bottom.

Approval By Specified Users​

The second designated approver workflow is the specific users workflow. In this workflow only users on the approvers list may approve software. Users will need to interact with and ask only these approvers.

Additionally admins may configure threshholds where multiple approvers can be required before approval is granted.

Approval By Members of a Tag​

The third designated approver workflow is the specific users workflow. In this workflow only users who are members of a group mapped to a specific tag may approve software. This is useful if admins have rotations or otherwise use group membership to rotate who can approve software.

Admins may configure threshholds where multiple approvers can be required before approval is granted.

Social Voting​

In social voting, any user in the specified tags can vote to approve an application. Each vote counts towards the local and global threshholds. Once an application has met the local threshhold (must be 2 or greater) the users in the tag that have voted to approve will receive an allow rule.

After the local threshhold has been met additional votes will add the allow rule to those users who have voted.

Upon reaching the global threshhold an allow rule is pushed out for the tag.

Additionally multiple tags can be joined to share votes. This allows different user populations to share approvals for common software will still allowing for other restricions to remain.

Setting this approval workflow on the global tag provides a workflow similar to Google's Upvote the original Santa sync service.

Configuring Approval Workflows​

All approval workflows can be configured via the UI as part of the tag settings. Additionally, approval workflows can be specified via the UpdateApprovalWorklowSettings API