Permissions Reports Strategy

[Daniel Tyger, geändert vor 9 Jahren.]

Hi,

We are using 6.2EE w tomcat / mysql and have a long history of sites with many pages, content objects, documents, etc. We want to create a reporting solution that allows site managers to review all the permissions against various objects within the site.

We have installed and configured the ReportsEE and JasperReportsEE portlets and researched the bitwise permissions utilized in Liferay 6+. We have constructed complex queries that retrieve the permissions from the database and format / configure them w iReport Designer and create corresponding JRXML files.

The queries run in less than 15 seconds and the reports export nicely in PDF, HTML, XLS, and CSV formats.

Is this a sound strategy?

Would there be performance ramifications if these reports are run during busy usage periods (perhaps they should be scheduled to run only at specific times)?

Is anyone interested in similar reports? Is there a place to share JRXML files?

Is there a better way to collect the permissions against a wide variety of portlets in a site? (I have specific reports for web content, page/layout, and document library completed, but would like a report that grabs all deployed portlet permissions of a site.)

Here is a example query to extract permissions against Doc Lib folders of a given site...

Last thing I would love to do is understand how I might inject key / value pair into the JRXML report just before exporting them as the UI suggests - but not sure how this is achieved... any ideas? (In my query below, I would like to inject the site name into the query as a variable...) - I am attaching the Report Definition Upload screen where this seems to be possible...

Please contact if you have suggestions or would like to share reports.

select dlf.name Folder, 
dlfe.title File, 
r.name Role, 
(case when (rp.actionIds & 1) then 'VIEW' else 'No' end) P1,
(case when (rp.actionIds & 2) then 'Add-DISC' else 'No' end) P2,
(case when (rp.actionIds & 4) then 'DELETE' else 'No' end) P3,
(case when (rp.actionIds & 8) then 'Del-DISC' else 'No' end) P4,
(case when (rp.actionIds & 16) then 'PERMS' else 'No' end) P5,
(case when (rp.actionIds & 32) then 'UPDATE' else 'No' end) P6,
(case when (rp.actionIds & 64) then 'Upd-DISC' else 'No' end) P7,
(case when (rp.actionIds & 128) then 'OvChkout' else 'No' end) P8
FROM resourcepermission rp 
JOIN role_ r ON (rp.roleId = r.roleId) 
JOIN dlfileentry dlfe ON (rp.primKey = dlfe.fileEntryId)
JOIN dlfolder dlf ON (dlfe.folderId = dlf.folderId)
JOIN group_ g ON (dlf.groupId = g.groupId)
WHERE 
r.name != 'Owner' AND
g.name = 'Guest'
order by Folder;

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

Looks great, Daniel.

I think it would be great if you shared this info, perhaps a Liferay blog or dev.liferay.com contribution? Previously I would have suggested a wiki page, but they're busy turning that down...

I think it is important to highlight that the query will only identify guest permissions due to the simple guest group check. A check for user permissions can get overly complicated if a user gets a role because they happen to get it from a parent organization, etc.

Even guest permissions can seem overly generous at times. You can, for example, give guest access to a document, but unless you offer some way for a guest to pull it, they really can't get to it. Same sort of thing in other cases, you can give guest access to a portlet on a page, but if guest cannot view the page then the guest access on the portlet doesn't matter.

These cases are most likely edge cases, and I don't want to take away from the value of the work you've offered to share. I'm thinking more about newbies and how they might take the output of the report as the soup-to-nuts evaluation of their current permissions configuration.

[Daniel Tyger, geändert vor 9 Jahren.]

David,

It looks like Liferay does not allow me to make a Blog entry. How does one acquire such a right? Thanks - daniel

[Daniel Tyger, geändert vor 9 Jahren.]

David H Nebinger:

...I think it is important to highlight that the query will only identify guest permissions due to the simple guest group check....

David - the g.name='Guest' is narrowing the results down to a Liferay Site (not a permission) and does return all of the various permissions against all documents housed within that site's doc lib. This way, it's easy to generate reports for each of our major Sites' objects...

I have made similar reports for web content objects, doc lib folders, pages and a few other commonly-deployed portlets.

You make a great point about inherited permissions from Organizations (thank you). In our case, we don't use Organizations (yet), so are unaffected by that nuance.

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

Spot on, Daniel. It's also important to note that a user has guest permissions also, so anything a guest can see a user can see.

I'm not picking on your work, Daniel, as I'm sure it's covering all of your own requirements, I'm just pointing out for others stumbling onto this thread.

As far as how to get blogging access, I'd suggest reaching out to James Faulkner. If he can't do it himself, I'm sure he'll know who can turn it on for you.

[Daniel Tyger, geändert vor 9 Jahren.]

David, Thank you. I did not intend to sound defensive. I don't feel the reports are yet comprehensive and could be improved significantly. I could see an entire plugin of built-in awesome reports being a valuable tool for everyone. We recently got some mileage out of the "Portlet Location Tracker" which has a nice drop-down list of all the plugins and draws a report of every page in the portal that has that plugin deployed. Creating a report plugin with similar drop-down menu selections for permissions reports, user / group / role reports, etc might be achievable with some focused or crowd-sourced effort. I am grateful for your replies. Also want to mention your blog articles and forum replies on Liferay have been very helpful to us. I have contacted James and will follow through on sharing this out to the community for further input and inspirations. Cheers, David. -daniel

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

The whole permissions system Liferay uses is both extremely flexible yet also at times hard to understand.

At the lowest level, you have a permission such as VIEW. This you will typically give to Guest. But the permission can be granted to one or more roles, and these roles can be granted to users, groups, organizations, site users, ... Add to that the inheritance of roles via parent organizations, ...

That's complicated enough, yet on top of that you have additional layers.

You can define a site (which has permissions), add to it a page (which has permissions) and place a portlet such as web content display on the page (which has permissions) and point at a web content article (which has permissions).

You can't just have permissions to one of these, you need permissions to all of them (except, of course, for search which can find content that you have access to but doesn't have the other constraints).

Fortunately most Liferay setups do not get so complicated, but the possibility is always there. Ends up being a rats nest

[Daniel Tyger, geändert vor 9 Jahren.]

David H Nebinger:

Looks great, Daniel.

I think it would be great if you shared this info, perhaps a Liferay blog or dev.liferay.com contribution?...

I have posted this article: https://www.liferay.com/web/daniel.tyger/blog/-/blogs/liferay-6-2ee-resource-permissions-reports
and will create a git repo soon for the .jrxml files...

Thank you for suggesting it, David.