Roles & Permissions
DAZZM engineered a unique way to control user access called Can Access. Instead of using a typical Role and Permission system which could get tricky to troubleshoot, our approach was designed to provide the flexibility to align perfectly with any application’s needs. For instance, user access could be regulated in one application by assigning one or multiple roles to each user. In another application, users could be assigned to a role or be part of groups, and just like with Active Directory, the group would dictate the user’s permissions. Another way to implement permissions with our system would be to assign a user to a project, giving that person implicit rights without needing to change that user's privileges.
Access control in DAZZM is highly customizable, supporting the implementation of complex business conditions. A manager’s access, for instance, can be limited to viewing only their own employees. Similarly, permissions can be configured to ensure that only the project owner has the authority to modify the "project code" field. DAZZM’s granular approach to access control can block a specific field level in cases involving an entity or enum. Additionally, Permissions and Business Rules can be combined within a single canAccess expression. For example, you might define a rule as:
currentUser.hasPermission('canManageAuthorisationCode') && data.amount > 10000.Furthermore, the platform does not filter Aggregates. If a user only has partial access to a list of invoices, this must be mirrored in the list's criteria. Otherwise, the backend will block access to the entire list.
DAZZM’s method can limit users from reading and writing data managed from native APIs as well as ones specific to the application. It combines backend and frontend parameters to provide a seamless user experience. On the backend, access can be removed from an Aggregate or blocked at the field level. For example, access to the Employee aggregate or the Salary field can be revoked. Access to the data is secured at the server level, and the UI of the application should be designed to match the user's access. The platform automatically hides fields that a user cannot access; however, it will not automatically hide aggregate labels. For example, if a user doesn’t have permission to view the employee's salary, but does have access to the employee’s detail page, the field label will need to be hidden using a Show Component Based On A Condition behavior with a Can Access condition.
After long consideration, DAZZM opted to open everything to everyone by default. Applications that don’t require roles and permissions will be ready to use immediately. It’s easier to add restrictions where they are needed than to grant permission everywhere. This places the responsibility on Solution Creators to ensure that Can Access rules are applied correctly when adding new commands, pages, and data. If a user attempts to execute a command or an API they don’t have access to, the system will display an error message. However, this message is intended for the Solution Creator during the testing phase of Can Access.
How the platform reacts to different scenarios:
canAccess on a Field in a List | The value disappears in the column when a canAccess is applied to the field.
|
canAccess on a Field on a Page | The value disappears but the field remains visible on the screen. To hide the field, add a visibility condition using canAccess.
|
canAccess on a Command | Interacting with the field does not trigger the command.
|
canAccess on an Aggregate – Error Message | This is what happens when the front-end allows a user to access a list page they are not authorized to access.
And this is what happens if a user tries to access a detail page without permission:
|
canAccess on a Detail Page | From the list, users can no longer click to view the details.
|
canAccess on a List Page | Scenario: The user can access the Opportunities list but cannot open an invoice detail page. In this example, the user does not have access to the detail page from the application's sidebar.
|
How do you filter a list page? | The platform does not filter aggregates automatically, so developers must apply the necessary filtering conditions on the user’s end. In addition to the CanAccess on the accountManager aggregate, the access rule must also be reimplemented in the list criteria, using a Set Component Data with a criterion so that the list only displays authorized data. For example, we could filter the list to only display accounts manager by the user. To do so, use a Set Component Data with criteria (account equal currentUser) on the list.
|
.gif "image001(4).gif")
.gif "image002(30).gif")
.gif "image003(14).gif")
.gif "image004(12).gif")
.png "image005(4).png")
.gif "image007(10).gif")
.gif "image008(9).gif")
.gif "image009(12).gif")
Updating CanAccess: Refreshing User Permissions Automatically When Editing Access Rules
When roles or permissions for a user are updated, DAZZM’s CanAccess feature allows the application to refresh and apply the new access rules automatically. However, this functionality requires prior configuration by the Solution Creator.
It's important to understand that the system does not automatically detect changes to the permission model, as these rules are implemented in JavaScript. For instance, if a rule is defined in canAccess for a query, specifying that only users from the same department can view the data, this might be expressed as:
currentUser.department.$isSame(data.department)How does the system know when to refresh the application?
The system cannot infer that an action, such as User::changeDepartment, affects the currentUser.department field used in canAccess. To address this, you must explicitly tell the system which actions impact user permissions by marking them with the Has impact on user access attribute. Once this attribute is assigned, the system will know to reload the application for the affected user after executing the action.
For example, if the User model includes a role field and a changeRole command, the same procedure must be applied to the changeRole command.
.png "image(117).png")
What happens when a role’s permissions are updated?
If a role, such as the ‘Manager’ role, is modified to grant access to certain data (e.g., enabling the canViewFinancialData permission via the Role:modifyPrivileges command), you must also mark the modifyPrivileges command with the Has impact on user access attribute to ensure the system knows the user permissions have changed and requires a refresh.
How does the system identify the users to be refreshed?
To specify which users should be refreshed, you must assign the Impacted users attribute to the relevant command. This attribute should return a list of all users affected by the modification. For instance, in a scenario where a role is modified, the system will refresh all users assigned to that role.
.png "image(115).png")
Rather than using a search command, you can directly reference a field that contains the list of affected users.
|
|
|---|
.png "image(119).png")
.png "image(120).png")
The Impacted users attribute ensures that only the users directly affected are refreshed, minimizing disruptions for others. In conclusion, it is crucial to note that the Impacted users attribute is mandatory. Without it, the automatic refresh will not be triggered for users currently in session.
Limitations & Roadmap
Certain features are currently unsupported, which could hinder the solution’s deployment in a production environment. First, access control does not govern metrics, impacting both the user interface and the underlying APIs. As a result, an authenticated user with sufficient technical expertise could potentially invoke the API to retrieve data that their permissions would typically restrict. To mitigate this, solution designers must develop dashboards that adjust visibility based on user access. Additionally, there is currently no method to create metrics that account for access control, such as generating a graph that only displays data for projects accessible to the current user.
This limitation presents a significant challenge for platform design; as of now, there is no identified solution to address it.
Furthermore, JavaScript is required to configure access, as the canAccess attribute only supports JavaScript expressions.
Status: Before introducing a no-code alternative, we aim to gather user feedback on the effectiveness of the current solution and analyze various use cases for canAccess to determine the most suitable no-code approach.
Conclusion
The DAZZM platform provides a robust and flexible system for managing user access, allowing Solution Creators to tailor permissions to meet specific business needs. Using CanAccess for fields, commands, and aggregates, you can control access precisely and ensure the system behaves as expected. However, developers should be aware of the limitations and ensure that they manually configure certain aspects like aggregate filtering and automatic permission updates.