« Torna a Features

Permissioning

Introduction #

This article explains the inner details of how the permissions system works in Liferay. And it does so by examining each of the tables (and therefore the entities) and the relationships that are involved in the security logic. The following ERD diagram shows the relationships among all the entities that are going to be explained:

Basic entities #

Let's start by examining a few tables called "entity" tables. In other words, they define entities in the system that can have permissions/roles attached to them.

User_ #

The most obvious entity is the User. In the simplest terms, permissions is all about asking the question, "Does this user have permission to do this action on this thing?"

Organization_ #

Users can belong to only one Organization and one Location. The confusing thing about the data model is that we use the same table to represent both. Basically, if the parentOrganizationId column has a -1, then it's an Organization, and if it's any other number, it's a Location. The "only one Organization and one Location" rule is maintained through logic in our code...not through data integrity. The logic also enforces that the Organization that a User belongs to must be the parent of the Location that the user belongs to. Users inherit permissions/roles from the Organization and Location that they belong to.

UserGroups #

Users -> UserGroups (Collection of Users)

Users can inherit permissions/roles from UserGroups. In Liferay 4.4, parentUserGroupId column is not yet being used.

Group_ #

Group is the old name for what are now called Communities. Users can belong to any number of Communities and inherit permissions/roles from them. Notice that in the Group_ table, there is a className and classPK column. If className and classPK are blank, then the record is a Community. If className is com.liferay.portal.model.User, then the record represents a private user community (only applies to Power Users). If className is com.liferay.portal.model.Organization, then the record represents an Organization or Location. If className is com.liferay.portal.model.UserGroup, then the record represents a UserGroup.

The reason for having Group records representing Organizations/Locations and UserGroups is to have one entry in this table for each entity in the system that represents a set of users. This simplifies relationships of other entities (such as permissions or roles) with these sets of users.

Permissions and Roles #

A permission is defined as an ACTION acting on a RESOURCE. Permissions can be assigned directly to a User or inherited through different means. A collection of permissions is known as a Role.

Resource_ #

A resource is a representation of an object in the portal...anything that you'd want to slap a permission on. It could be a portlet, a community, a user, a message board topic, a blog entry...whatever. Let's take a quick look at each of the columns in the Resource_ table:

  • resourceId = The unique id of the resource
  • companyId = The company that this resource belongs to
  • name = The "name" of the object that this resource represents. If the object is a portlet, it's the portletId. If it's a class, it's the fully qualified package name of the class
  • typeId = For the time being, we're only concerned with permissioning classes, so this value will always be "class". However, in the future, we might start permissioning files or folders, so typeId might take on the values of "file" or "folder".
  • scope = The possible values are "company" (we refer to it as "Enterprise Scope"), "group" (we refer to it as "Community Scope"), or "individual" (we refer to it as "Individual Scope"). Why the different naming conventions? Because things change... The numeric values for scope (as found in the database) can be found in the class com.liferay.portal.model.impl.ResourceImpl

Permission_ #

As stated earlier, a permission is an action acting on a resource. Therefore, the Permission_ table has an actionId and resourceId column. As expected, the resourceId column references the resourceId column from the Resource_ table. However, the actionId column doesn't have a corresponding Action_ table. All actionIds are defined in the ActionKeys class. Wanna know how to define new actions for resources? Read Implementing Permissions

Role_ #

This is the table where a role is defined. Really, the only important column is the name column because roles must have unique names.

Roles_Permissions #

This is the relational table that links a permission to a role. Without these links, roles would be useless...they'd just be empty containers.

Assignment of users to communities and organizations #

Users_Groups #

This is the relational table that links a User to a Community. You're probably wondering why we don't have a className and classPK column in this table so we could handle all entities (e.g., Communites, Organization/Locations, UserGroups) in one table. Again, too hard to explain, but trust us...it's better this way.

Users_Orgs #

This is the relational table that links a User to an Organization/Location.

Users_UserGroups #

This is the relational table that links a User to a UserGroup.

Assignment of roles and permissions #

Users_Permissions #

This is the relational table that directly links a permission to a user.

Users_Roles #

This is the relational table that links a role to a user. The user then inherits all the permissions linked to that role (via Roles_Permissions).

Groups_Permissions #

This is the relational table that links a permission to a Group. Remember earlier in our discussion how we said a Group_ record could either represent a Community, Organization/Location, or UserGroup? Well, this is the table that directly links those permissions to each of these entities. And then of course, users that belong to these entities would inherit the permissions. Notice there is no Orgs_Permissions or UserGroups_Permissions tables. Groups_Permissions is enough to handle all cases. Maybe now it makes more sense why this is simpler.

Groups_Roles #

This is the relational table that links a role to a Group. Just like for Groups_Permissions, a Group could either refer to a Community, Organization/Location, or UserGroup. Users that belong to these "Groups" would then inherit the permissions from the corresponding roles.

Groups_Orgs #

This is the relational table that links Organizations/Locations to Communities. In other words, an admin can assign every User that is part of a particular Organization or Location to a Community. As a result, any permissions or roles assigned to that Community would now be inherited by every User in the selected Organization/Location

Groups_UserGroups #

Exactly the same reasoning as Groups_Orgs, except for UserGroups

OrgGroupPermission #

Here's the oddball of the bunch. This table is used for "Exclusive Permissions". Basically, a user has to belong to a particular Location (or Organization since Liferay v4.4) AND a particular Community to receive this permission. By the way, though the OrgGroupRole table exists, it is never used in our code.

Let's see why this option is useful with an example. Within a community there is a message boards, and the administrator wants to set up a category of the message boards so that only the users that belong to a given location can post to it. So he clicks the 'Permissions' icon for that category and selects the appropriate location. Now ALL users of the location will be able to post, regardless of whether they are members of the community or not.

In some circumstances, the administrator may want to restrict this further, saying that the user must also belong to the organization to post to that category. This is done by setting "Exclusive Permissions".

1 Allegato
81169 Visualizzazioni
Media (3 Voti)
La media del punteggio è 3.0 stelle su 5.
Commenti
Commenti Autore Data
This is so good, thanks!!! Dafna Fernandez Burguera 26 marzo 2009 4.27
Hi, I checked the DB and seems the reference to... Giuseppe Calignano 7 aprile 2009 7.12
Hello, is this still up-to-date with Liferay... Lorinc Nyitrai 11 maggio 2009 4.15
This diagram was created for 4.4 and is only... Jorge Ferrer 14 maggio 2009 6.54
Is there an updated diagram. article, or... jeff Leitman 16 settembre 2009 13.13
Can you create a link for displaying the graph... Nicolas Muller 7 giugno 2010 0.57
Hi, Is there an updated document that explains... Banji O 6 dicembre 2010 12.53
Permissions in Action check this ... Rohit Salecha 9 maggio 2011 6.37
I agree that we need an update to this... Bruce Altner 31 maggio 2011 5.50
Attached the ERD diagram in addition to the... Johannes Fleck 14 luglio 2010 4.33
Very usefull information but should be updated... Anton Finders 12 agosto 2010 1.26
This is very useful, especially to those new to... Pete Marshall 17 settembre 2010 1.03
- Where can i find the ER-Model of the all the... lpu123 xyz 29 settembre 2010 20.20
- Oh, I see: the tables do not have "FOREIGN... lpu123 xyz 30 settembre 2010 10.13
It would be really nice to have an updated... Oliver Hagmann 6 febbraio 2012 2.36

This is so good, thanks!!!
Inviato il 26/03/09 4.27.
Hi,
I checked the DB and seems the reference to "resource_ " table is wrong.
Resorce_ have the follow fields:
-resourceId
-codeId
-primKey

The table wiht above fields is resourcecode

I use liferay 5.2.2 with MySql DB
Inviato il 07/04/09 7.12.
Hello,

is this still up-to-date with Liferay 5.1.4?

Thanks!
Inviato il 11/05/09 4.15.
This diagram was created for 4.4 and is only valid for algorithms 1 to 4. Several things have changed since then so it should not be taken as an accurate source of information. Anyway it's still very useful to get a general understanding of the permission system.
Inviato il 14/05/09 6.54 in risposta a Lorinc Nyitrai.
Is there an updated diagram. article, or explanation somewhere for 5.2.3? The Portal Admin Guide and the Development docs from 5.1 do not have this level of detail, and the example of a MessageBoard administrator does not begin to cover the potential possibilities of permissions and resources.

My company wants to use the portal for a purpose other than an intranet, and should the powers that be decide to go with this, it's very likely that we'll want to subscribe to the enterprise benefits.
Inviato il 16/09/09 13.13 in risposta a Jorge Ferrer.
Can you create a link for displaying the graph in full mode. In fact it is truncated :-(

Thank a lot !

Best regards
Inviato il 07/06/10 0.57 in risposta a Jorge Ferrer.
Attached the ERD diagram in addition to the embedded version. All tables can be viewed now.
Inviato il 14/07/10 4.33.
Very usefull information but should be updated for >LR6.
Inviato il 12/08/10 1.26.
This is very useful, especially to those new to Liferay. Is this going to be updated - especially now version 6 is released?
Inviato il 17/09/10 1.03 in risposta a Anton Finders.
- Where can i find the ER-Model of the all the tables in the database?
- I have tried to reversed generate the ER-Model with MySQLWorkbench, but no relationships were generated ! Why ? Any Ideas?
Inviato il 29/09/10 20.20.
- Oh, I see: the tables do not have "FOREIGN KEY REFERENCES", so they do not have the relationships-constraints between the tables!
Inviato il 30/09/10 10.13 in risposta a lpu123 xyz.
Hi,
Is there an updated document that explains the team permission model in LR6?
Inviato il 06/12/10 12.53 in risposta a Jorge Ferrer.
Permissions in Action check this

http://liferaydemystified.blogspot.com/search/label/Liferay%20Permissions
Inviato il 09/05/11 6.37 in risposta a Banji O.
I agree that we need an update to this information, which is seriously out of date. The promised update at Rohit's blog site was not there when I checked (other useful information was there but not what I was hoping to find).
Inviato il 31/05/11 5.50 in risposta a Rohit Salecha.
It would be really nice to have an updated version of this and also if parts of it would also be written from a users and not a developers perspecitve. As a user I'm not interested how the database tables are organised but more which action in the interface has what effect.
Inviato il 06/02/12 2.36.