Summary
In a complex application decisions have to be made whether a person is allowed to perform a certain action. This is frequently encountered in Dynamic Case Management applications where a user is only allowed to perform a subset of tasks. You may also encounter it in applications without process engine, where the end user is not allowed to see certain information based on some criteria.
As the user permission example does not concern the core business rules of a company, but a way of structuring the work of its employees, is the Application Layer the appropriate location for this scenario (arrow 5). External systems may use the same logic for deriving user permissions (arrow 4).
Security is a separate concern and ideally should not be mixed with the core of the domain. When mixed, these could intertwine and get more difficult to maintain. Having these separate, makes it clear what is authorization, and what is core business. |
Contents
Problem
A good example can be found in a DCM application for mortgage applications. Based on the current application the system has to decide whether the Junior Mid-Office employee is allowed to make the approval decision, or if a more senior role is needed. The stakeholders may decide that any property with a value under half a million can be done by junior employees, while anything above has to be done by a senior employee. Furthermore the user should not have performed previous tasks for the application, to adhere to the four-eyes principle.
The problem of this case is not how to create such logic, as that is perfectly doable using Blueriq's rule engine. The problem lies in the maintainability of the application. Logic for user permissions is different to other logic (e.g., calculating a mortgage amount) and mixing them may decrease the maintainability. User permissions concerns the manner in which knowledge workers interact with the system, not with the domain at hand.
Decouple Category
Properties
| Property | Description |
|---|---|
| Decouple category | Application function (5) |
| Complexity | Low |
| Related patterns/Solutions |
|
Solutions
Webservice
It is possible to create an authorization web service. This could be a BAAS, or created in some other manner. This web service would return the users roles based on the user ID, and other important information concerning the current application, such as the property value. This pattern is a suitable fit as user set results are appropriate and the authorization might be needed by other applications as well.
Function
A Blueriq function can be created which handles the authorization question. This function is then distributed across Blueriq applications. This pattern is suitable as user-set results are a good fit, as well as likely simple parameters suffice. The high reusability of this pattern allows us to easily check whether a user has permission in different applications or contexts.
External rule
The derivation whether a user has a certain role within the given context can be implemented using an external rule. It would either derive a boolean attribute which indicates that the user is allowed a certain action or not, or derive a set of roles of a multivalues string attribute. The decision what a user is allowed to do, is taken in code. The code has to read the appropriate attribute values from the domain to come to its decision.
Module with Flow
A separate user authorization module can be created which is distributed as library across projects. In it is a domain with authorization rules, and a flow which takes the decision. You might not even need the flow if everything is handled by the rule engine. The calling application has to make sure to fill the appropriate attributes with values when calling the flow, or when the authorization is needed. The support of dependencies and the decision requirements graph make this pattern interesting.
Issues and considerations
The preferred pattern for this problem is Decoupling Pattern 5: Function. It has the knowledge characteristics required for this problem, namely that values are user set and support for parameters, so that the same authorization function can easily be used in different applications/contexts with a different domain. The high reusability and testability make the implementation of this mechanism simple.
Decoupling Pattern 2: Webservice call is also a suitable pattern but it is more complex to implement due to the data mappings, and the reusability of these data mappings can be a problem in this example. Furthermore, in this example the authorization is likely only used internally, and the focus of a web service lies on external consumers.
The advantages which Decoupling Pattern 6: External Rule and Decoupling Pattern 1: Module with Flow have in terms of integration with the rule engine are not utilized in this example. An authorization is usually only done when loggin in or when opening a case. The inference mechanism is then simply not needed. As these patterns score low on maintainability characterstics, the other patterns are preferable.