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

PropertyDescription
Decouple categoryApplication function (5)
ComplexityLow
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.

 

 

 TypeScoreDescription
Knowledge characteristicsUser set or System setUser set

User-set values enter the profile, which are set from the returning message and the subsequent data mapping.

Parameters or complex modelParameters

Only simple input/output parameters could be used with Web services (BaaS). The input and output parameters are neatly defined in the contract of the web service. You are able to steer what values are set in the data mapping. If you want to fill in the  parameters differently for different calls from the same module, an additional data mapping and AQ_WebServiceClient service call needs to be created.

Enhanced by Blueriq Functionality(blue star)Blueriq can use dependencies up to the contract. There are no decision requirement graphs or dependencies possible between the calling application and the BAAS.




Maintainability characteristics

It should be possible to quickly make changes to business rules independent of other functionality.

        
Focus on Internal or External UseExternal

A web service is intended for external use, and relies on an official contract definition.

Low Implementation complexity(blue star)(blue star)You get two additional modules in your project, and a second project next to it. As you are in control of the information being send, the structure will be similar to what you use in the application module. Therefore the mapping should be easy (1 to 1). You have to create your own contract for the communication, and keep this updated.
Internals invisible (encapsulation)(blue star)(blue star)(blue star)Internals are not visible and/or accessible of a web service.
Autonomous(blue star)(blue star)(blue star)The business rules are executed in a separate profile, and no side-effects are possible.
Highly Testable(blue star)(blue star)(blue star)Webservices are easily testable.
Highly Reusable(blue star)A BaaS implementation is not very reusable because of a lack of parameter support. Hence, for every web service call a mapping must be defined.
Out of the Box(blue star)(blue star)(blue star)No custom code required in general.


Deployment characteristics 

Part of Application or Separate Deployment (=deployment)Separate DeploymentAs soon as a new version is deployed, all consumers directly use the new version. When web services are versioned, the calling party can decide itself when to migrate to a new version.

 

 

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.

 TypeScoreDescription
Knowledge characteristicsUser set or System setUser

Any output of a function call in a flow is made user set and the rule engine can not overwrite it.

Parameters or complex modelParameters

The function call support simple in- and output parameters.

Enhanced by Blueriq Functionality(blue star)(blue star)In- and output parameters are validated and dependencies can be shown.




Maintainability characteristics

It should be possible to quickly make changes to business rules independent of other functionality.

        
Focus on Internal or External UseInternal

Although a function can be exposed as web service, the focus is on internal use.

Low Implementation complexity(blue star)(blue star)(blue star)Functions are easy and lightweight. The only significant complexity gain is due to an additional module in your project, which does not need to be connected in any manner.
Internals invisible (encapsulation)(blue star)(blue star)(blue star)The internals can be viewed if wanted, but when using a function there is no need to do so. You only see the in- and outputs of a function and there is no mental load on the Business Engineer with the internals.
Autonomous(blue star)(blue star)(blue star)The business rules are executed in an own separate profile and do not mingle with the profile of the calling application.
Highly Testable(blue star)(blue star)(blue star)These functions can be unit tested in studio, as well as automated as regression tests that call it as web service.
Highly Reusable(blue star)(blue star)(blue star)You import a function into a project as library, and are ready to use it.
Out of the Box(blue star)(blue star)(blue star)No custom code is needed. 


Deployment characteristics 

Part of Application or Separate Deployment (=deployment)Part of the ApplicationA function is distributed as library, and that model becomes part of the application.

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.

 TypeScoreDescription
Knowledge characteristicsUser set or System setSystem

An external rule is part of the truth maintenance mechanism and any result is system-set.

Parameters or complex modelComplex Model

On the external rule parameters can be defined which trigger the truth maintenance. In code you however access to the complete profile, and can use any attribute during the calculation. Although it is best practice only to use the truth maintenance parameters, we classify this as complex model.

Enhanced by Blueriq Functionality

(blue star)(blue star)(blue star)

/

(blue star)

External rules are part of truth maintenance mechanism. However, there are dependencies for the truth maintenance parameters, but there is no way of knowing what happens in the external rule or what attributes are actually needed. In these cases it is not possible to rely on truth maintenace mechanism.




Maintainability characteristics

It should be possible to quickly make changes to business rules independent of other functionality.

        
Focus on Internal or External UseInternal

External rules are only used by Blueriq.

Low Implementation complexity(blue star)(blue star)There is a simple hook, and the code that needs to be written is simple. The difficulty lies with keeping the code in line with the model, as the external rule reads attribute values in a hard coded manner.
Internals invisible (encapsulation)

(blue star)(blue star)(blue star)

/

(blue star)
The internal code is not visible from the model. From the code however, you can view the entire model.
Autonomous(blue star)As the complete profile can be input to the external rule, changes in it may lead to side effects during the execution of the external rule. In addition, code and models are highly coupled so it is difficult to test the model autonomously. There is always a strong dependency with code.
Highly Testable(blue star)(blue star)Unit tests can be written in code. the difficulty lies in the hard link to the defined model. When the model changes, the code might break as it is hard-coded what attributes are needed.
Highly Reusable(blue star)Once you have the external rule defined, then you can distribute the definition in a library and use it simply on any desired attribute.The domain needs however be very similar, as the code reads the values of certain attributes in a hard coded manner. When different attributes are needed for another application, then the code needs to be changed.
Out of the Box(blue star)An external rule requires writing of code. 


Deployment characteristics 

Part of Application or Separate Deployment (=deployment)Part of ApplicationThe code has its own life-cycle and is deployed separately. It is however strongly coupled with the domain of an application. This leads to the code moslty only be used by one application. Therefore, we regard it as part of the corresponding application.

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.

 TypeScoreDescription
Knowledge characteristicsUser set or System setSystem set

As the underlying module is included, the rule engine can do its work.

Parameters or complex modelComplex Model

The entire function can be used as output. There are no clear input parameters defined.

Enhanced by Blueriq Functionality(blue star)(blue star)(blue star)This pattern is enhances by Blueriq functionality, as model validations, the Decision Requirements graph, dependencies and specifications keep working.




Maintainability characteristics

It should be possible to quickly make changes to business rules independent of other functionality.

        
Focus on Internal or External UseInternal

This pattern purely covers internal use. The business function is included in a Blueriq library.

Low Implementation complexity(blue star)(blue star)Including a library is done quickly and easily. The complexity can however increase drastically in case that many libraries are used and stacked, or if many projects need updates from the same library. When many specializations are present, then the complexity is high.
Internals invisible (encapsulation)(blue star)All internals are visible and increase the mental load of the business engineer. Mistakes may be made when elements are used which were not supposed to be used.
Autonomous(blue star)The business rules are executed in the context of the main application. When the main application uses internals of the library, then making changes generates side effects.
Highly Testable(blue star)(blue star)The library can be tested on its own, either by unit tests in studio or with special test applications. When the application gets larger testing larger chunks of model can get difficult.
Highly Reusable(blue star)(blue star)Including libraries by hand can be time-consuming when the number of projects becomes large. The Blueriq Control Center can help with many projects.
Out of the Box(blue star)(blue star)(blue star)This is possible without custom coding. 


Deployment characteristics 

Part of Application or Separate Deployment (=deployment)Part of ApplicationThe library has to be imported into a project and becomes part of it.

Issues and considerations


  • No labels