| Authorisation model |
| |
|
Authorization is made possible at several levels.
This ranges from access control at page level to fine grained authorization of data at field level by means of business rules.
|
| |
|
All application objects associate authorization attributes with the services which are provided.
Application objects are authorized based on the relevant context object and the authorization rules.
If the authorization rules deny access, the service is not accessible.
It is also possible to apply authorization at data level.
In which case provided the user is authorized only the data field is accessible.
|
| |
|
Authorization attributes are assigned to objects by means of constraint objects.
Constraint objects carry out the authorization based on the context, which is available through the application object.
Examples of constraints are user name, role within the application, organization and involvement of a dossier.
|
| |
 |
| |
|
Since components themselves are responsible for authorization before the execution of logic, it is possible that a component adopts certain behavior without the parent component being informed.
An example of this is a dossier in a table which generates no output, because the user is not authorized to see this record.
The table has no knowledge of the fact that the record is not in the result set.
|
| |
|
The framework offers a number of constraints to implement authorization.
Each of these constraints require a number of attributes which have to be configured.
Moreover each constraint consists of a pair of standard attributes: 'type' and 'attribute'.
With 'type' it is possible to indicate if a an action is allowed or disallowed.
With 'attribute' it is possible to indicate the type of action to perform: to read, add, update or remove.
|
