Liferay Permissions + specifying exclusions

[Andrew Jardine, geändert vor 8 Jahren.]

Hey Guys and Gals,

I've come across a need that I am not sure the portal offers. I am hoping that I am wrong and that in fact it DOES do it, just that I am not aware of HOW to do it. Let me start by creating a scenario.

Users

• Tom (manager)
• Mary (manager)
• Fred (employee)
• Sally (employee)
• Andrew (consultant)

Let's assume that my system has 3 Roles:

Roles

• Consultant
• Employee
• Manager

And that I have created 2 User Groups

User Groups

• Managers
• Employees

Now. I create a page (Home) that I want everyone to see -- so for the VIEW action I check the box for all three roles (Consultant, Employee, Manager). I create another page (Reports) and I want to assign all managers to this page, but exclude Tom. So basically I want to assign the VIEW permission to the Manager role for the Reports page, but then I want to remove Tom from being able to see it, even though he is a manager. This is the sort of thing that you see when you are working with permissions in Windows -- you have a box that let's you choose the people/groups that are allowed, but then also an exceptions area.

I know what some of you might say but I am illustrating a very simple example here to make it easy to understand. I am sure you can appreciate that in a large organization you can't just create thousands of Roles and User Groups to try to meet all permutations. Apart from the maintenance nightmare that brings, it would be a performance failure.

So my question is this --

Is there a way in Liferay to provide this type of functionality? Allow all the individuals/groups in this role to, for example, VIEW this permission, unless they are in this list of groups or users?

I really hope the answer is yes

[David H Nebinger, geändert vor 8 Jahren.]

Sorry, the answer is no

The problem is that there is no connection with the page and the permission check. There would be a general permission check, "is Tom a manager" and the response to that is yes. Since it is yes, then the reports page is available. There's no permission check for "is Tom a manager while on the reports page" sort of thing.

[Olaf Kock, geändert vor 8 Jahren.]

In addition to David's answer: Especially from big organizations I'm hearing that they're rather creating a nightmare of permission permutations from certain very flexible permission systems - allowing you to respecify and exclude on every (of many) different levels. As a result you feel like you're more flexible but in fact you soon loose oversight over who has been granted what permission on which part.

Another related thing that I'm seeing often: More often than not permissions are used to mimic relevancy - something that shouldn't be done through permissions. This is a very big aspect in creating complex permission systems. Before limiting access to certain people, try to see if "relevancy" or "interest" is the reason for the document not to be shown. This can and should rather be implemented in a different way: "Show relevant information" rather than "Show what I have access to". Audience targeting - even though typically showcased with targeted ads - is one way to approach, but by far not the only one.

[Andrew Jardine, geändert vor 8 Jahren.]

Hi Guys,

First off, thanks to both of you for answering -- though I was pretty sure that it would be one or both of you that I heard from ;)

I agree that it can start to get a little hairy -- specifically what you said Olaf about "How do I know what 'Managers' have access to" or how can I know what "Tom has access to" when his Roles may not reflect his rights. I think in a perfect world you are right just providing grants would be all that is required. But in my scenario we're talking about a really large solution with over 40,000 users that span not just different groups, but also organizations etc. The solution being built is being done so in hopes that it will replace an existing legacy system that provides that "these people/groups have access, and these don't" kind of scenario. So as a result my client is trying to apply this same solution to Liferay -- which obviously won't work.

Part of what I am proposing is to break the monolith site into a series of targeted sites. I'm also proposing the introduction of site based roles or even teams to help solve this. I think that this sort of stuff will help eliminate SOME of the edge cases but they want the flexibility to, in a pinch, exclude some users.

One thing I was thinking of doing -- which may sound insane but I was poking around with it today and it might not be THAT insane -- is to create a custom permission checker that extends from the AdvancedPermisionChecker and then AFTER the parent calls are complete add additional logic in the custom class to do a secondary check for an "exclusions list". I realize of course this means wrapping some services and some JSP hooks to modify the permissions screens -- a lot of work, but do you think it would be possible?

If not, can you give me an example, based on how Liferay works today to tackle this problem without creating a performance nightmare? Right now there are literally hundreds of roles (one role for every group in the old system) and the permissions box takes up to 6 seconds to load -- never mind the seemingly endless list of roles to scroll through!

[Olaf Kock, geändert vor 8 Jahren.]

It might be an option to just use the document library as storage (with fully protected, no-one can-read, documents) and build your own service on top of it, that implements its own permission algorithm. Validate if this would make maintenance easier (because it's all in one place and not intermixed with Liferay's code) or harder (because you'll have to rewrite the UI). However, I think the biggest challenge you face is in UX and providing the overview over who is allowed to do what.

[Tomas Polesovsky, geändert vor 8 Jahren.]

Hi Andrew,

from technical perspective this can work. You just need some caching and simple exclusion rules probably only between User-to-Object or Role-to-Object.

With this you need to update UI screen displaying a single Object permissions and include the exclusions for user/Role.

However, if the list of exclusions is huge - Tom cannot access not only this page but also 1000 others + 10.000 documents and you have 100's of "Tom"s, this is unmanageable, insane job to check all the checkboxes from UI. With this you would need a more general rules, but with them is harder to see the ends.

[Andrew Jardine, geändert vor 8 Jahren.]

Hi Tomas,

Thanks for the input -- and I totally agree about the manageability. What I was thinking is perhaps this might be best managed by have an "exclusion" role for each of the cases. So essentially, you add a user, or a user group in the UI, and then behind the scenes this would assign the user/group to a "exclusion" role. The role could perhaps be "lazy created" or something so that they only exist when there are actual exclusions in place. To be honest, it is very early in my exercise to determine how many exceptions there would be so this is really just an expeditionary mission at the moment.

Thanks for all the feedback guys -- I'll let you know where we land and post a solution if we do something custom.

[David H Nebinger, geändert vor 8 Jahren.]

I'd argue that affirmative permissioning is always better than implementing an exclusionary policy.

The issue is that Tom right now is an outlier, but tomorrow you may decide that both Dick and Harry should also not see the reports.

So managing an affirmative role of "Can See Reports" is more effective because there's no exclusions to keep track of and manage separately. The perceived simpler case of "all managers except Tom, Dick and Harry" begins to break down as your exception list grows. "Can See Reports" is easier to manage whether internally within Liferay or externally.