Skip to main content

Authentication & Authorization

Components

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โ€‹

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 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โ€‹

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.

info

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.

Read moreโ€‹