(r6) XeoPrimerSecurityReference < WebXEO

WebXEO Web>XeoPrimer>XeoPrimerSecurityReference (revision 6) (raw view)~~EditAttach~~
-- Main.PedroRio - 27 Jan 2011
---+ XEO Security/Permissions

The XEO framework has a set of bult-in security/permission system 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 Labelling (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" Object 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 <em>description </em>attribute and includes a collection attribute ( _rules_) which are instances of the Ebo_PolicyRule Object Model. The Ebo_PolicyRule Object 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 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 performa 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.

[[XeoMainAdmin][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 Object Model and 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 a runtime feature, 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, of course).

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

<img width="800" alt="" src="%ATTACHURL%/OPL.png" height="342" />

__Figure SecRef.1 - OPL editing in an Object Model__

Voltar cá

___
---+++ 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.

Object Models, Attributes, Method and Object Model Instances can be labeled with a KEY/ACTION pair ( *N percebo o que é isto*, ver formação Toni)

The comparison between the keys of the user and the keys of the object/action the user is trying to use will allow the system to determine if the user has sufficient privileges. ( *VER ISTO NOVAMENTE*)

*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);_

_

*JUNTAR AQUI INFORMAÇÃO SOBRE CLASSKEYS*

_
---+++ 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", "Delete the 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 permisison system you must enumerate them in a text file named "ProjectSecurableViewers.txt" with a viewer name per line, like in the following example:
<pre><verbatim>Main.xvw
MyObject/edit.xvw</verbatim>
</pre>

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

__
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	OPL.png	manage	49.5 K	2011-01-27 - 17:59	PedroRio
Topic revision: r6 - 2011-02-16 - PedroRio
No permission to view TWiki.WebTopBar
No permission to view TWiki.WebBottomBar