Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Did you look at "permissions"?  Create an attribute definition for each set of departments in a security group.  assign who can use it as READ/UPDATE on that permission attribute definition.  Make the names.  It difficult to explain these things over email, maybe slack me a doodle poll and we can discuss some options?  🙂

Would be nice to have form element control on attributes, that could help.  And security over the values.

Do the people assigning know the code values?  i.e. could they type them in?  If so, maybe an attribute and instead of picking the attribute name, just type in the value?  Or comma separated values?  A rule can validate that the user can access to the value and can veto if not?

There is an up and coming provisioning feature that allows "metadata" on a membership to be provisioned.  This could be a drop down and we could integrate security so the list is secure.  Maybe this could be used in future?  🙂

---

From: <> on behalf of Jonathan Keller <>
Sent: Thursday, January 14, 2021 4:54 PM
To: <>
Subject: [grouper-users] Structuring Scoped Roles in Grouper

 

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