This article explains the Security Domain Model used to control access to and within Conductor accounts.
A User is an entity that can use a Conductor Account. A User is granted certain Authorities. Authorities determine the actions the User can perform, the data the User can view, and the assets the User can control.
An Account defines the domain of security, assets, and data for a group of Users. Every Account is unique and has at least one User, usually the individual/entity who created the Account. New Users may be added to an existing Account by an existing User of the Account (assuming that User holds the proper granted Authorities to add new Users).
UserGroups are used to map Users to Policies. A User that is a member of a UserGroup is granted all the Authorities defined by the Policies associated with the UserGroup.
A special type of UserGroup is created for each Account, which denotes the owners of that Account. No Policy is needed for this type of UserGroup. Members of the owners UserGroup are granted all available Authorities for the Account.
A Policy is a set of Authorities. Policies are associated to a UserGroup to assign Users a set of Authorities.
An Authority is an Operation-Resource pair that defines whether an Operation can be performed on a Resource. Authorities are added to a Policy to grant permissions to Users. Examples include CREATE_User, READ_uplinkPayloadData.
A Resource is an entity available within Conductor. Resources are defined in order to group certain functions and to allow for those functions to be permitted via Authorities. Examples of Access Model Resources are Users, Accounts, and Policies. Examples of Data Model Resources are uplinkPayloadData, and avgSignalMetadata.
An Operation is an action that can be executed on a Resource. Examples are CRUD operations (create, read, update, delete). an Operation-Resource pair forms an Authority.