Grouper Users - Open Discussion List

[Jonathan Keller <>]

Permission being the type on the attribute definition?  Briefly  I was having trouble with the Assign To values and attaching the attributes where I expected to be able to attach them.  It felt like Permission -> Limit was intended for this, but at the time,
 I wasn't able to get it configured, so fell back to attribute while I experimented.  (Found an issue where you can't change the type of an attribute definition via the UI once it has been created.)

And, yes, they know the values and could type them in as I did in my test setup below.

Thanks for the offer - I'm going to tinker a little more with permissions and see where that gets me.  My main goal here was to make sure I was not going in a completely wrong direction with attaching this type of data within grouper.

--

Jonathan Keller

Application Architect - Administrative IT

On Jan 14, 2021, at 2:47 PM, Hyzer, Chris <> wrote:

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

<image001.png>