XEO Security/Permissions

The XEO framework has a set of built-in security/permission systems to make it easier to develop your applications. There are three types of securities/permissions in a XEO Application, listed as follows:

• Object Model Permissions (Permissions)
• Object Policy Labeling (Security)
• Viewer Permissions (Permissions)

Object Model Permissions - Policies

Object Model Permissions allow you to define a system of permissions around Object Models. You can define that only a certain "set" of people can create/edit/delete instances of a certain object model, or only a certain set of people can see a particular attribute in an Object Model, or execute a given method in that Object Model.

This allows you do define a rule such as "Only the Managers group can see the "Total Project cost" in a given Project (assuming there's a group representing the managers, and a "Project" XEO Model with an attribute representing the total cost of the project).

A Policy is an instance of the system Ebo_Policy Object Model which has a name and a description attribute and includes a collection attribute ( rules) which are instances of the Ebo_PolicyRule Object Model. The Ebo_PolicyRule XEO Model is the key factor here, as each instance of of Ebo_PolicyRule defines the regular name and description attributes but also the type of rule (which can be "Read, Write, Delete, Execute and Create") it is and which groups (instances of Ebo_Group) can make that action.

In a XEO Application, if no policies are defined (the default for a new application), every user can perform every action (Read, Write, Delete, Create and Execute) over every Object Model, Attribute and Method.

Important Notice: Policies are not hierarchical, i.e. if a user can delete instances of a certain Object Model it does not mean he can create new ones, or edit existing ones.

If a given action over a certain Object Model/Attribute/Method is not defined, every user can perform that action. Example: If the "CREATE" action of Object Model "A" is allowed only for users of group "B", only those users will be able to create an instance of A, but every user will be able to read, edit, delete and execute instances/attributes/methods of A.

To create Policies you need to go to the Administration Page to the Security Section.

__

Object Policy Labeling (Security)

Object Policy Labeling (OPL) is a way to define which set of users (or individual users) can read/write/delete or have full control over a specific instance of an Object Model.

In order to do that you need to declare the OPL feature as active in a given XEO Model and declare Attribute Keys for specific actions (READ, WRITE, DELETE and FULLCONTROL). OPL Actions are hierarchical, if a user has write permission it also has read permission, OPL is a security feature created at design/development time (not created at runtime, like Policies).

If no OPL is defined in a given Object Model all users can perform all actions on instances of that model (if no other permission policy is in place, naturally).

To declare OPL, use the graphical editor in XEO Studio for editing a XEO Model, and go to the OPL section, like depicted in figure SecRef.1

Figure SecRef.1 - OPL editing in an Object Model

OPL - ClassKeys (Custom OPL Rules)

If you need an OPL rule that cannot simply be defined as explained above, you can make use of the OPL Class Keys mechanism. The Class Keys mechanism allows you to make a custom implementation of OPL and choose when and how read/write/etc permissions are granted to a given user on a given instance.

In order to make of the Class Keys mechanism you must implement the netgest.bo.security.ISecurityClassKeys interface, which has the following methods:

public long[] getReadKeys(boObject object) throws boRuntimeException;
public long[] getWriteKeys(boObject object) throws boRuntimeException;
public long[] getDeleteKeys(boObject object) throws boRuntimeException;
public long[] getFullControlKeys(boObject object) throws boRuntimeException;

All of the methods in the ISecurityClassKeys interface return an array of numbers, representing the Business Object Unique Identifiers (BOUIs) of the users, groups, roles or functions that have the given permission (read, write, delete or full control) for the instance passed as parameter (boObject object). Using this mechanism you can create complex permission rules, like giving a user read privilege over certain instances only on the first monday of each month, between 10.00h and 11.00 h.

_

Notes about OPL and Policies and the general Permission mechanism:

XEO OPL and Policies rely on keys (specifically BOUIs). Each user in a XEO Application has its own BOUI and the BOUI of all the Groups/Roles/Functions it belongs. Ebo_Group instance can define hierarchies (sub-groups) a user by making part of a group also has the keys of all its sub-groups.

Policies take precedence over OPL, i.e. If a certain Policy blocks a user from writing on a given instance, even if he has an OPL action which allows writing in that instance he will not be able to write it.

The XEO Framework Java API and XEOQL follow these permission/security rules, however:

• The SYSUSER account can always execute any action
• It possible to programatically bypass securities and permissions, if needed:
  • boObject.setCheckSecurity(false);

_

Viewer Permissions (Permissions)

Viewer Permissions is a feature similar to Policies, but applied to Components inside a viewer. To declare Viewer Permissions you'll have to select a specific viewer, search for the component where you want to declare permissions and add a new Access Policy (which includes choosing the action Read, Write, Delete, Execute, Add and/or Full Control) for a specific user/group/role.

Important Notice: Not all actions apply to every component. For example to a xvw:menu component only an "Execute" action will apply, while to a xeo:bridge component the "Add", "Read" and "Delete" actions will apply.

Viewer Permissions are, contrary to Object Model Policies, hierarchical. If a user has full control permission over a given component it will have read, write, add, delete and execute permissions over the component.

In order to declare which viewers can be subject to this permission system you must enumerate them in a text file named "ProjectSecurableViewers.txt" with a viewer name per line, like in the following example (this file must be in the root directory of tour source code folder):

Main.xvw
MyObject/edit.xvw

To define a viewer permission you must go the Administration page of a XEO Application.

__