Foren

Permission Model

thumbnail
Ray Augé, geändert vor 16 Jahren.

Permission Model

Liferay Legend Beiträge: 1197 Beitrittsdatum: 08.02.05 Neueste Beiträge
Hey All,

I know I'm know for beating a topic to death... but with regard to past
suggestions I've made that perhaps we should drop user permissions in
favour of only role permissions... I've just read a
WikiPedia entry which supports this
notion:

http://en.wikipedia.org/wiki/Access_control_list
en.wikipedia.org/wiki/Access_control_list:
ACL-based security
models

In an ACL-based security model, when a subject requests to perform an
operation on an object, the system first checks the list for an
applicable entry in order to decide whether or not to proceed with the
operation. A key issue in the definition of any ACL-based security model
is the question of how access control lists are edited. For each object;
who can modify the object's ACL and what changes are allowed.

Systems that use ACLs can be classified into two categories,
discretionary and mandatory. A system is said to have discretionary
access control if the creator or owner of an object can fully control
access to the object, including, for example, altering the object's ACL
to grant access to anyone else. A system is said to have mandatory
access control (also known as "non-discretionary access control" in the
security literature) if it enforces system-wide restrictions that
override the permissions stated in the ACL.

Traditional ACL systems assign permissions to individual users, which
can become cumbersome in a system with a large number of users. In a
more recent approach called role-based access control,
permissions are assigned to roles, and roles are assigned to
users.


In our case, it would be a matter of simply pulling out the user
permissions... this would greatly reduce data complexity and increase
performance due to much less processing spent in evaluation.

We wouldn't lose any power of permissions either... because we're still
free to create as many roles as we like... once for each user if that is
what is required in some special case... BUT this would NOT be the
normal case.

Thoughts?

Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
thumbnail
Ed Shin, geändert vor 16 Jahren.

RE: Permission Model

Junior Member Beiträge: 71 Beitrittsdatum: 24.03.05 Neueste Beiträge
I'm also in favor of dropping user based permissions. I don't mean to repeat what Ray already said, but I think there will be minimal loss of functionality for big gains in performance and reduction in complexity.

I really hope that we go with this change!
thumbnail
Andre Kreienbring, geändert vor 16 Jahren.

RE: Permission Model

Regular Member Beiträge: 152 Beitrittsdatum: 18.12.06 Neueste Beiträge
Hi,

It depends on the question how much speed the system can gain.
What about the "oh so often" special cases: A person has a role but needs some extra permission?

André
thumbnail
Ray Augé, geändert vor 16 Jahren.

Re: [Liferay Forums][Liferay Core Developers]RE: Permission Model

Liferay Legend Beiträge: 1197 Beitrittsdatum: 08.02.05 Neueste Beiträge
> It depends on the question how much speed the system can gain.
> What about the "oh so often" special cases: A person has a role but needs some extra permission?


Create a new role with the missing permissions and grant that to the
user???

This way, you can apply the missing permissions to N users with N
operations... rather that N*(# of P) operations.
thumbnail
Jorge Ferrer, geändert vor 16 Jahren.

RE: Permission Model

Liferay Legend Beiträge: 2871 Beitrittsdatum: 31.08.06 Neueste Beiträge
Hi,

I'm for it too.

What I think we should do is create a property to control this. If this property is set to false then user permissions are not checked and the UI is hidden. That way if someone still needs the flexibility they can set the property to true.

By default I would set the property to false and see what happens. If after some time nobody is using it we can just remove user permissions completely.
thumbnail
Ray Augé, geändert vor 16 Jahren.

Re: [Liferay Forums][Liferay Core Developers]RE: Permission Model

Liferay Legend Beiträge: 1197 Beitrittsdatum: 08.02.05 Neueste Beiträge
> What I think we should do is create a property to control this. If this property is set to false then user permissions are not checked and the UI is hidden. That way if someone still needs the flexibility they can set the property to true.
>
> By default I would set the property to false and see what happens. If after some time nobody is using it we can just remove user permissions completely.


Again... this is a discussion to get peoples input... I don't expect
these changes to occur in the next trunk commit... emoticon

I think that we need to hear all the arguments FOR user permissions...
and find out where they are valid... and IF there are valid reasons that
are good enough to justify having a slower more memory intensive
portal...

Consider this as the THE biggest issue:

BECAUSE of user permissions we can't do this:

Give me all the documents in folder X that I can VIEW.


Without user permissions the queries used to make such a query
would be considerably more feasible... With user permissions they
are absolutely not feasible... and this applies to every single entity
model in the portal.
thumbnail
Wilson Man, geändert vor 16 Jahren.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Permission Model

Liferay Master Beiträge: 581 Beitrittsdatum: 21.06.06 Neueste Beiträge
i second (or sixth) the idea of dropping user perm in favor of role perm. I think in our UI, we can still show the user perm ... but in the backend, just use Role perm to achieve that when needed transparently.
thumbnail
Ezequiel Chavez, geändert vor 16 Jahren.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Permission Model

Regular Member Beiträge: 135 Beitrittsdatum: 20.01.06 Neueste Beiträge
Hi,

I developed a generic security model on top of Spring Security (Acegi) to centrally manage permissions on the resources of the different applications of the company, Acegi force the use of role-based privileges, but is sufficiently flexible to extend.

The key is to bring together Groups, Roles and Users in a single concept that is Credential, permissions over resources are based on credentials, every user has a set of credentials, by default its user himself is a Credential, a user can be associated to Groups and Roles, a Group may have a set of Roles.

Now on the other hand we have the resources, which can be protected by permissions, What is a Permission in my model? is a association between a Resource, a Credential and a Privilege.

Since a Credential can be a Group, Role and User, I can set permissions for a resource at three levels.

A simple example:

Users = user1, user2
Groups = group1, group2
Roles = role1, role2, role3

user1 is associated with group1
user2 is associated with role2 and group2

group1 is associated with role1, role2, role3
group2 is not associated with any Role

then user1 credentials are cred_user1 (himself), cred_group1 (directly associated), cred_role1 (inherited from group1), cred_role2 (inherited from group1), cred_role3 (inherited from group1)
and user2 credentials are cred_user2 (himself), cred_role2 (directly associated), cred_group2 (directly associated)

Resources = res1, res2, res3
Privileges = exec, save, update, del

Permission = perm1(Resource = res1, Credential = cred_group1, Privilege = exec)
Permission = perm2(Resource = res2, Credential = cred_role1, Privilege = save)
Permission = perm3(Resource = res2, Credential = cred_role2, Privilege = del)
Permission = perm4(Resource = res3, Credential = cred_user2, Privilege = update)

From this we can say that:
  • user1 does have permission on res1 for "exec" privilege
  • user1 does have permission on res2 for "save" privilege
  • user1 does not have permission on res2 for "del" privilege
  • user1 does not have permission on res3 for "update" privilege
  • user2 does not have permission on res1 for "exec" privilege
  • user2 does not have permission on res2 for "save" privilege
  • user2 does have permission on res2 for "del" privilege
  • user2 does have permission on res3 for "update" privilege


I have a simple Class Diagram of this model, but i can't upload files in this thread emoticon , I hope that you can catch the idea that I wanted to convey.


Regards.
thumbnail
Alexander Chow, geändert vor 16 Jahren.

RE: Permission Model

Liferay Master Beiträge: 518 Beitrittsdatum: 20.07.05 Neueste Beiträge
Hey Ray,

This is something that we have talked about for a great deal in which I agree with. It is both faster and more admin-friendly.

I would, as Jorge suggests, allow for a switch to enable or disable user-level permission control. This simply because there may be some enterprises who actually like the user-level control. There is also the question of migration -- how do you migrate enterprise who have already began using the user-level permissions?

This might be a different discussion than where you are going Ray, but I wonder if we can change some of the logic. Really, if you look at the code, the permission check does a select count(*) for all the permissions granted to a particular user, role, etc. -- each separate calls per permission. That's five separate DB hits per permission. I wonder if we can also explore algorithms to (1) check against all permissions simultaneously or (2) more intelligently check against the relationships.
thumbnail
Jesper W, geändert vor 16 Jahren.

RE: Permission Model

Expert Beiträge: 310 Beitrittsdatum: 25.03.07 Neueste Beiträge
Maybe a slightly broad statement, but I would tend to vote for anything that simplifies the permission model ...
In it's current shape it is so complex it is not transparent even to knowledgable people.
(Like myself emoticon )

Bug report ^^^ Emoticons aren't working....
thumbnail
Shivani Chandna, geändert vor 15 Jahren.

RE: Permission Model

Junior Member Beiträge: 54 Beitrittsdatum: 17.07.07 Neueste Beiträge
I was facing issue of adding permissions to journal content - getting the authorization information from another sub system.
Since the journal content was a multiple instance liferay portlet - I was faced with the following issues:

1. How to differentiate one journal content from another (all share the same liferay portlet definition file so cannot use portlet preferences)

2. Where to define specific journal content permission information?

Finally, I used tags in journal article to associate authorization information to the journal content portlets. (Adding new tags were not given as a feature to end user - so I could go ahead with this approach). At run time, I fetch the user and portlet info and then combine them and query my subsystem.

Is there any way, in which liferay could enable permissioning in journal content based on some criteria and call the user defined permissioning class?. This model could be then extended to be used for any liferay portlet.

If I wish to use both liferay permissioning as well as my own sub system permissioning,I had to change the PortletPermissionImpl.java in portal-impl package. (or create a similar file in ext env). Could we simplify this - through change of permission model?.

-
Shivani.
Ravish Bhagdev, geändert vor 11 Jahren.

RE: Permission Model

New Member Beiträge: 3 Beitrittsdatum: 13.04.12 Neueste Beiträge
I agree fully with the suggestion. The permissions model is overly complex and needs to be simplified with ACLs and roles.

It is currently impossible to perform search efficiently. If we can store ACLs alongside each indexed item, it will be impossible to know how many of hits a user is allowed to see before it goes through the highly inefficient permissions checker. It will be even worse if we had to recompute facet counts for search results depending on whether a user is allowed to see an item or not.

Anyone know if anything is being done about this at all?
thumbnail
Hitoshi Ozawa, geändert vor 11 Jahren.

RE: Permission Model

Liferay Legend Beiträge: 7942 Beitrittsdatum: 24.03.10 Neueste Beiträge
The topic of this thread was switching from user permission to role permission. This has long been changed. Are you suggesting something else beside the current permission algorithm used in Liferay 6.1?