Skip to Content.
Sympa Menu

grouper-users - [grouper-users] Fine-Grained Permissions

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] Fine-Grained Permissions


Chronological Thread 
  • From: Dennis Roberts <>
  • To:
  • Cc: Sriram Srinivasan <>, Nirav Merchant <>, "" <>
  • Subject: [grouper-users] Fine-Grained Permissions
  • Date: Mon, 23 Nov 2015 18:59:22 +0000

Our organization recently attempted to use Grouper permissions to store permissions user-defined resources, called "apps", in our system. We have more than 9000 users and more than 6000 apps. This is the permissions model that we tried:

iplant:de:users:de-users - role containing all users
iplant:de:apps:app-permission-def - permission definition for apps, with actions, read, write and own
iplant:de:apps:<app-id> - permission name for a single app
iplant:de:apps:public-aps - permission name for public apps in general

Everyone in the de-users role has read access to iplant:de:apps:public-apps, and every public app inherits its permissions from iplant:de:apps:public-apps. Public apps currently have no permissions assigned directly to them.

Each private app has one permission assigned to it that grants the app owner own permission. Private apps do not inherit permissions from iplant:de:apps:private-apps.

After setting up the initial permissions, I attempted to query the Grouper Web Services for the permissions associated with a single app. The service call timed out after a few minutes. I also tried querying the grouper_perms_all_v and grouper_perms_role_v views directly using very restrictive queries (on the case of grouper_perms_role_v, a query that that searched for a single role, and permission name. All of the tables in the database were analyzed after I imported these settings and before I ran this query. I canceled the query after several minutes.

There was a warning in one of the instructional videos indicating that fine-grained permissions may need to be cached. My suspicion at this point is that our permission requirements are too fine-grained to work at all. Is this the case, or is there something about the permissions model that we're using that's causing this slowness?

Thanks,
Dennis




Archive powered by MHonArc 2.6.16.

Top of Page