KIE Community

Permissions

• View a perspective 
• Save a project 
• View a repository 
• Delete a dashboard 

A permission can be granted or denied and it can be global or resource specific. For instance:

• Global: “Create new perspectives” 
• Specific: “View the home perspective” 

As you can see, a permission is a resource + action pair. In the concrete case of a perspective we have: read, update, delete and create as the actions available. That means that there are four possible permissions that could be granted for perspectives. 

Permissions do not necessarily need to be tied to a resource. Sometimes it is also neccessary to protect access to specific features, like for instance “generate a sales report”. That means, permissions can be used not only to protect access to resources but also to custom features within the application.

Authorization policy

The set of permissions assigned to every role and/or group is called the authorization (or security) policy. Every application contains a single security policy which is used every time the system checks a permission.

The authorization policy file is initialized from a file called WEB-INF/classes/security-policy.properties under the application’s WAR structure.

NOTE: If no policy is defined then the authorization management features are disabled and the application behaves as if all the resources & features were granted by default. 

Here is an example of a security policy file:

# Role “admin”
role.admin.permission.perspective.read=true
role.admin.permission.perspective.read.Dashboard=false

The next screenshot shows how this new perspective looks:          

Security Management Perspective

Compared to the previous version this new perspective integrates into a single UI the management of roles, groups & users as well as the edition of the permissions assigned to both roles & groups. In concrete:

• List all the roles, groups and users available 
• Create & delete users and groups 
• Edit users, assign roles or groups, and change user properties
• Edit both roles & groups security settings, which include: 
• The home perspective a user will be directed to after login 
• The permissions granted or denied to the different workbench resources and features available 

All of the above together provides a complete users and groups management subsystem as well as a permission configuration UI for protecting access to some of the workbench resources and features.

Role management

By selecting the Roles tab on the left sidebar, the application shows all the application roles:

Unlike users and groups, roles can not be created nor deleted as they come from the application’s web.xml descriptor.

NOTE: User & group management features were described in detail in this previous article. 

After clicking on a role in the left sidebar, the role editor is opened on the screen’s right, which is exactly the same editor used for groups. 

Security settings editor

Security Settings 

NOTE: In the example above, the Update and Delete permissions are disabled as it does not makes sense to define such permissions if the user is not even able to read perspectives.

Security Policy Storage

The security policy is stored under the workbench’s VFS. Most concrete, in a GIT repo called “security”. The ACL table is stored in a file called “security-policy.properties” under the “authz” directory. Next is an example of the entries this file contains:

role.admin.home=HomePerspective 

Every time the ACL is modified from the security settings UI the changes are stored into the GIT repo. Initially, when the application is deployed for the first time there is no security policy stored in GIT. However, the application might need to set-up a default policy with the different access profiles for each of the application roles. 

• Check if an active policy is already stored in GIT 
• If not, then check if a policy has been defined under the webapp’s classpath 
• If found, such policy is stored under GIT 

The above is an auto-deploy mechanism which is used in the workbench to set-up its default security policy.

One slight variation of the deployment process is the ability to split the “security-policy.properties” file into small pieces so that it is possible, for example, to define one file per role. The split files must start by the “security-module-” prefix, for instance: “security-module-admin.properties”. The deployment mechanism will read and deploy both the “security-policy.properties” and all the optional “security-module-?.properties” found on the classpath.

Notice, despite using the split approach, the “security-policy.properties” must always be present as it is used as a marker file by the security subsystem in order to locate the other policy files. This split mechanism allows for a better organization of the whole security policy.

Authorization API

@Inject
AuthorizationManager authzManager;

Perspective perpsective1;
User user;
...
boolean result = authzManager.authorize(perspective1, user);

authorizationManager.check(perspective1, user)
    .granted(() -> ...)
    .denied(() -> ...); 

The security check calls always use the permissions defined in the security policy.

Summary