User Management
The User Management system of PixelCore serves two purposes. First, it is used to authorize users and applications connecting to the Platform. Second, user groups are used for access permissions configuration. Access Permissions model is described in another section.
Users¶
Access to the Platform is only possible for authorized users. Basic user data, including usernames and passwords, is stored in Users records. There are two types of accounts: users and applications. They are described by the same data structure, but they can be displayed differently and different sets of actions can be available for them.
All accounts store the information required for authorization (usernames and passwords), as well as additional contact information. Users are combined into User Groups. User Groups are used to define access permissions to almost all major data types within the Platform. By logging in to user applications, such as Pixel Admin, a user interacts with the system on behalf of its account and exercises the rights of the groups that this user belongs to.
Applications include all software products that have access to the party data, both external and internal (for example, drivers). An account is created for each application, and its data is used to organize interaction between the application and the core. Depending on the access rights, the application can only read data from the party, and can write its own data, change the data of other applications, send and receive various commands defined by the creators of the application.
User groups¶
A User Group by its name is a group of users within the Platform. Users can belong to multiple User Groups. User Groups are used for access control configuration: for each major data type within the Platform a set of three groups can be specified which implement different types of rights.
The rights of each particular user to a particular element of the system are determined by the groups in which this account is included.
Platform allows the creation of as many User Groups as needed.
Nobody and Anybody groups¶
There are two system User Groups which have some special meaning:
- Nobody User Group
- Anybody User Group
Those two groups are permanent and can’t be changed or deleted. All Users in the Platform automatically belong to Anybody Group. So if one needs to grant access to everyone within the Platform, it can pick Anybody User Group.
Also in the case if some User Group was deleted but before it was used to configure access permissions for some data within the Platform, the Anybody User Group would be automatically applied to those data instead of the group which was deleted.
In the case when one wants to forbid access to some data type within the Platform, Nobody User Group can be used for this purpose. No user can belong to this group, it is always empty.
User Profiles¶
Profiles are service Objects that are linked to user accounts and store information that applications need to work with these users. The profile may store information such as personal interface settings, notification settings, and additional user information.
A profile is also an Object which is based on a Schema. It is created by the application and can have an arbitrary set of properties - it depends on what data about the user the application needs to store.
User's Profile is a platform feature which means that all setup (instantiation) of the User Profiles is automated by the Platform. The check for existence (and creation if it doesn’t exist) of User Profile happens on authorization stage. User’s Profile are Application specific which means that the same User can have multiple User’s Profile depending on which Application name was provided during authorization. If no Application name was provided during Authorization stage then Profile setup function is not called.
The Profile setup algorithm¶
If there is an Object created using a schema tagged "user profile" and "
If no such Object was found, the Platform tries to create an Object using a Schema defined by tags "user profile" and "
Summary, to take advantage of the profile feature, you need:
- to be authorized by specifying the application name (for instance "admin")
- to have a Schema available describing a profile structure and containing tags "user profile" and "
" (for instance "admin") - to have within this Schema property named “User:UserID” for the Platform to be able to store User’s login information for matching.
Actions on Users¶
PixelCore supports some essential automated processing on certain actions taken with Users via PixelCore GraphQL API or corresponding UI.
User disable & User delete¶
In the case of disabling the User (User.enabled = false) or deletion of the User, PixelCore beside updating the field itself or deleting related entry, removes all Refresh Tokens, Access Tokens and Subscriptions (with forced disconnect) related to this User.
Essentially the Disabled User can’t be authorized within the Platform.