# Security

Uberfire provides a complete authorization management subsystem for protecting user access to specific resources or features. In order to understand how the security mechanism works a few core concepts need to be introduced first.

#### Roles and groups

Users can be assigned with more than one role and/or group. It is always mandatory to assign at least one role to the user, otherwise he/she won’t be able to login. Roles are defined at application server level and they are part of the webapp’s web.xml descriptor. On the other hand, groups are a more flexible concept, since they can be defined at runtime.

#### Permissions

A permission is basically something the user can do within the application. Usually, an action related to a specific resource. For instance:

• 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 home perspective”

As you can see, a permission is a resource + action pair. In the concrete case of a perspective we have: save, delete, rename & copy as the available actions. That means that there exist 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 what's called the authorization (or security) policy. Every Uberfire application contains a single security policy which is used every time the system is checking a permission.

The authorization policy file is stored in a file called WEB-INF/classes/security-policy.properties stored under the application's WAR structure.

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


Here is an example of a security policy file:

# Role "admin"

# Role "user"


As you can see every entry defines a single permission which is assigned to a role/group. On application start up, the policy file is loaded and stored into memory.

#### Security checks

The AuthorizationManager is the main interface for checking if permissions are granted to users.

@Inject
AuthorizationManager authzManager;

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


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