Access Control

The State Store is partitioned by license key, which means that everyone who uses your license key will have full access to all of the Stack and Environment records associated with your license key.

This can be problematic if you also use the auth:salesforce:save command to save Salesforce credentials in either a stack or environment record, but you do not wish for everyone who uses your license key to be able to authenticate with every Salesforce organization linked to an environment. For example:

  • You're working for a client who has created a development environment for you but they do not wish to give you access to their Production Environment.
  • You have a change control manager who should be the only one capable of promoting changes to production, but you still wish for other people to be able to track other environments with OrgFlow.

Restricting access to Salesforce organizations

If you'd like (or need) to save Salesforce credentials on the stack or an environment, but wish to only have a subset of your OrgFlow users be able to use those credentials, then you should use a different @concept_envryptionkey for each group of environment credentials that you'd like to have restricted.

For example: Use encryption key A when setting base credentials with the auth:salesforce:save command. Then, use a different encryption key (B) to set the credentials for the production environment (again with the auth:salesforce:save command). Anyone wishing to authenticate with your production environment via OrgFlow will need to hold encryption key B, whereas anyone with encryption key A can authenticate with any other environment.

tip icon

This example takes advantage of @concept_credentialinferrence, which is a core concept when dealing to Salesforce authentication and OrgFlow.

Restricting access to backing Git branches

You may also wish to consider restricting access to the Backing Git Branch for sensitive environments. This would prevent someone from bypassing OrgFlow entirely and pushing changes directly to the branch.

Git doesn't natively support this kind of functionality, but a lot of Git services add this feature in one way or another (usually by allowing policies to be configured that restrict who can make changes to particular branches):

You should check with your Git service to see how best to implement this.

warning icon

If you choose to restrict access to Git branches, you should also take care if using auth:git:save command or auth:git:credentialhelper Git credential helper.

The Git authentication details set or retrieved by this command are globally available to everyone with your license key. So if you have used this command to save credentials for a user that has access to every Git branch, then anyone with your key could just use those credentials in place of their own.