The EVRYTHNG Platform includes several mechanism that allow configuration of granular access to resources within any given account. These make it possible to allow effective collaboration between team members with different needs and privileges, and also provides the security required where product and user data is concerned.
By default, these features provide an intuitive degree of access that is suitable for most accounts. However, for those that require more strict control of resources for access and security purposes, they are also highly customisable when combined and correctly configured. This page aims to help explain how these mechanisms work, and also how to achieve some of the most common requirements and scenarios.
The following gives a brief summary of each of the access control features available to developers to leverage in their integrations. More in-depth information can be found on the linked pages.
Operators and Access Tokens are the two different actors that our platform supports.
Both Operators and Access Tokens can have roles that define their access to the platform. What separates them apart is that an Operator is related to a user - a person that is signed into our platform, whereas an Access Token could represent, for instance, the authorised access for a software used by other systems, or a mobile application used by people that are not signed into the EVRYTHNG platform.
Both Operators and Access Tokens have an API key directly related to them. For example, each Operator collaborating as team members on a given EVRYTHNG account will have an Operator API Key that is unique per user, per account. Similarly, a given Access Token signed into our platform and part of a certain account will have an API Key that is unique per per account.
See API Keys and Key Permissions for more information about API keys.
Any given API key has at least one role that defines what that actor is reasonably required to do. By making use of the platform roles and assigning them to a given Operator, one could, for example, be able to read products and thngs, but not update or delete them.
Similarly, an Access Token could have a role that would only be allowed to read some specific resources and create specific actions.
See Roles and Permissions for more information about roles.
Beyond roles - that define what resources actors can access and the operations they can make on those resources - it is also possible to restrict access based on attribute filtering.
For example, a sourcing manager that is responsible for 10 different factories may only need access to data that is relevant to those factories. Moreover, factory administrators may only need access to data that is produced on their factories.
Read the Restrictive Conditions page to learn more information on how to restrict access using attribute filtering.
Updated 3 months ago