Dime.Scheduler has a granular, role-based access control security system that let the administrators do the configuration. It also has a data-driven mechanism which validates users against data.
Securing an application consists of two distinct areas: authentication and authorization.
Authentication is concerned about verifying whether the user is actually the person who he claims to be. A user can be authenticated using the following identity providers: Azure, Windows and forms login.
The first two types are managed by other systems (and you will probably use it for other applications too) while the latter allows you to use credentials that are used only by Dime.Scheduler. The latter option provides the easiest way to get started as no configuration or integration is required whereas the two others may need to be set up or configured.
Authorization is all about enforcing security clearance. This is where roles and user actions come into play. Dime.Scheduler logically groups features together and protects them with user actions. It is ultimately up to the administrator to assign user actions to roles, which in turn are assigned to users. Finally, there is also data protected security through the assignment of filter values, categories and time markers to users, which are then compared to tasks and resources.
As mentioned earlier, authorization is always granted to users. Depending on the setup, it could be that users will see very diverse projections of Dime.Scheduler. There are simple user actions such as "Global Administrator" which unlocks all features but there are also more subtle ones like the "Plan Project" action which protects the Gantt chart.
Where role-based access control (i.e. user actions and roles) defines what users can do, data-driven security defines what users get to see.
Even when two users have the same user roles, it is possible that they will different sets of data in the grids and planning boards. The opposite is also true: users may have very different roles but it is possible that they will see the same data in the components. What they can do with it depends on the roles and subsequently, the user actions.
📄️ Authentication Types
Both Dime.Scheduler's planning application and back office application require users to authenticate.
📄️ User Groups
The concept of user groups is very easy to understand. Instead of treating users individually, they can be grouped together and treated as one single entity. A user can be part of multiple groups but it is up to the administrator to decide which groups he belongs to.
📄️ Role-based Access Control
Roles, user actions and user (groups)
📄️ Data-driven security
As stated before, Dime.Scheduler has a layered security mechanism, much of which can be managed by administrators. First, roles and user actions define what the user can do in Dime.Scheduler. This is also known as role-based access control (RBAC). Besides this, a second category can be identified: data-driven security. The data users can access depend on the results of a simple matching algorithm, which will be elaborated in this document.