Configuring authorization

When we use the base component Account for authorization, we define access by configuring the DataAccess data elementData Element (DataElement). A fundamental data concept or entity within an application's domain, acting as an anthropomorphic translation of a real-life object or concept..

Data Access

To configure access to a DataElement, create a DataAccessRight instance with the following fieldsFieldA property of a DataElement expanded to a database column and user interface input element.:

• forProfile, forUser or forUserGroup: Set one of these fieldsFieldA property of a DataElement expanded to a database column and user interface input element. to define the target for the access right.
• element: Should be a concatenation of the component name and the element name with _ as separator. The element name should have the first letter in lowercase. For backwards compatibility it is also possible to just use an element name, but it is preferred to include the component name. Alternatively, componentName_* can be used as a wildcard for every element in a component or * for every element in every component.
• functionality:
• target: Should be a concatenation of element and functionality with _ as separator. [Deprecated: no longer in use]
• authorized: true or false (yes or no for backwards compatibility), when you want to enable or disable the right respectively.

Example

This data access would prevent a user from deleting car instances, but it can view them and execute a data operationData Operation (DataOperation). A type-safe action (e.g., Create, Update, Custom) executed on DataElement instances to modify data or trigger business logic..

	forProfile	forUser	forUserGroup	element	functionality	authorized
	user			rentalComp_car	status	true
	user			rentalComp_car	operation.addBooking	true
	user			rentalComp_car	delete	false

caution

The default policy is to allow all actions for any user. You change this implementation to instead use deny all by editing the account.ns.properties file.

Read customizing-authorization.mdx for more information.

List of access rights

The following values can be used in functionality fieldFieldA property of a DataElement expanded to a database column and user interface input element. to define an access right:

• Data elementsData Element (DataElement). A fundamental data concept or entity within an application's domain, acting as an anthropomorphic translation of a real-life object or concept.: Either create, modify, delete or status (status enables you to view and search data) for default CRUDs operations. all can be used as a wildcard for all functionalities.
• Data CommandData Command (DataCommand). [Deprecated] A legacy mechanism used for data input and custom action execution on DataElements, replaced by DataOperations.: For access to a DataCommand, the name of the command is used.
• Data OperationData Operation (DataOperation). A type-safe action (e.g., Create, Update, Custom) executed on DataElement instances to modify data or trigger business logic.: prefix the name of the dataOperation with operation. (e.g. operation.addBooking)
• API Endpoints: apiGetList , apiCreate, apiModify, apiUpdate , apiRemove see security.mdx

Priority

It is possible multiple AccessRight instances apply to the same user. In that case, the priorities are as follows:

• user-specific rights > profile rights > userGroup rights

This means that rights blacklisted by the userGroup can be whitelisted by the profile. But also the other way around: a profile can blacklist what a usergroup has whitelisted.

Generally, it is better to pick a single strategy for defining access rights, be it either through profiles or userGroups.

Authorization in Logic Layer

By default, authorization is only checked in the Control LayerLayerLogical separation of functionality within a single system/application, focused on code organization.. However, it is possible to extend these checks to the logic layerLayerLogical separation of functionality within a single system/application, focused on code organization.:

Option

useLogicSecurity Component

Generate authorization check in logic layerLayerLogical separation of functionality within a single system/application, focused on code organization..

With this option, security at component level can be achieved in the logic layerLayerLogical separation of functionality within a single system/application, focused on code organization..

This authorization is generated for standard CRUD operations, commands and tasks. This generated code will always call the AuthorizationManager of the new account component.

Example Code

The generated code in the TaskBean.perform() method:

DataAccessQuery dataAccessQuery = new DataAccessQuery();
dataAccessQuery.setElement(taskName);
AuthorizationManager authorizationManager = new AuthorizationManager(dataAccessQuery, userContext);
if (!authorizationManager.isTaskAuthorized()) {
    return TaskResult.error(Diagnostic.error("testComponent","CarTask", "NO_ACCESS"));
}

taskResult = mImplementation.perform(targetParameter);

The generated code in the DataBean.perform() method:

DataAccessQuery dataAccessQuery = new DataAccessQuery();
dataAccessQuery.setElement(elementName);
AuthorizationManager authorizationManager = new AuthorizationManager(dataAccessQuery,userContext);
if (!authorizationManager.isDataAuthorized(DataAccessFunctionality.CREATE)) {
   return getDiagnosticHelper().createCrudsError("not authorized");
}

The generated code in the DataBean.performCommand() method:

DataAccessQuery dataAccessQuery = new DataAccessQuery();
dataAccessQuery.setElement(elementName);
AuthorizationManager authorizationManager = new AuthorizationManager(dataAccessQuery,commandParameter.getUserContext());
if (!authorizationManager.isDataAuthorized(commandName))) {
 return CommandResult.error(command, "not authorized");
}

<options>
  <useLogicSecurity/>
</options>