Skip to Content.
Sympa Menu

grouper-users - [grouper-users] Structuring Scoped Roles in Grouper

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] Structuring Scoped Roles in Grouper

Chronological Thread 
  • From: Jonathan Keller <>
  • To: "" <>
  • Subject: [grouper-users] Structuring Scoped Roles in Grouper
  • Date: Thu, 14 Jan 2021 21:54:26 +0000
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CS9AfifktWa55dk+gbg794lZ+t4uzJRSK0yMwjYE3Hk=; b=PllDdGLsBKe+iLVFNAx33rctdtzA1wAIu3+fJkv1Ci06C/wt5NZo1YeFAdMquEh4vtk245yzarMyCgU7Kv5QqEwfL5Q4QP/snEJWoGhIH0xz8spXPeSPkui74qd/QxYb1+mbVtztUCGx8/kc/A4Lqa5FioM/hVj4Z0h3C06TLlVHE1MwpwoYVM/3m0lZupDJWn6NXXbSYr14NsJidRzv7hI5yX+VTlknbj+ie+zU+x8LDHkpt1VRLoEQ3bEHt78fwVDO8/KF+goWFNmjhrou/CX3NO3sCvaI7X+9Sg5XEAR8JittmORu+3KbW8LSjHp3pi4Co5ycaJVCpd91rUQghQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=UKqbTyeMRm+3VjBZzA+MTC/ydKGj3VXwM7enDhLwC9dibTNsEA/GHsEFYrQeQY3QJliu1nUCFoVPH6XOlq5zJSiZi1ss/eENnkR17eV1wKPbTdJhOnawy0d4vcWHsdGHy9PW44F1Wqnk0BQOequv9czuYbjm1dyUU93+stZ8/AiiNmO9ZtJPPnAlyn2c9YBL/SboZSIyLAnC2rPtMpekQbzdTpEFzGUOzc1m07Q+w+Uxrl3+EQZjVAhQkddVuG1CkOE88Nwb6kVzsthEHOY3RGLLatv0kuA68ZEAgsH0havkyIhqFggZyaaFHsi4oj9TwIh3dszUzXnau+X8790haQ==

TL;DR : looking for _A_ "right" way within Grouper to create policy groups with qualifiers (limits?) E.g., a manually maintained scoped role which would be used to limit a user's access to a set of departments for an external system.

In our existing system (Kuali Rice), we have the ability to assign qualifiers to role memberships.  We can then query that role using context data to see if someone has the role for a given department code.  I had been assuming that attributes could serve the same function.  (A custom process would be pulling this data via the API - so I'm fine with having to run a few calls to extract the data.)

But, the method for getting into the attributes and assigning them makes it feel like that is not really what they were designed for.  And, the visibility and maintainability of this through the UI is not great.  In the use case I am testing, we have people who are responsible for many different department codes (and some who only have one)

I toyed with the idea of just using department groups for these people, and adding them to those per-department groups.  But, I really didn't want to create yet-another-set of 600+ home department groups, just for one application.  Plus, for those who have responsibility for 50+ other departments, it seems that maintenance might be even more of a headache.

I've been banging around with the attribute definitions, and linking them, and getting them assigned to memberships such that I do have a setup like the following.  And, I am able (sort of) to pull it via the WS API.  But it just doesn't feel right, and that I might be creating a setup which would either be hard to maintain or might disallow the use of certain other Grouper feature to help maintain this group.

I'd appreciate any guidance this group might have on this.  We are just getting started with grouper on our campus, so are feeling out its capabilities and trying to map them against what we have as our group management system today.

Thanks in advance for any help.

Jonathan Keller
Application Architect - Administrative IT

Archive powered by MHonArc 2.6.24.

Top of Page