Grouper Users - Open Discussion List

[Jonathan Keller <>]

Yes - the discussion all helped.  I found and set up the permissions and have been able to successfully use the web services against them - both to pull all users with limits for a given role, as well as testing an "limit env var" value against the _expression_
 limit I put in.  As for my "designed" command - I was mainly looking at the attributes at that time and hadn't discovered the internal use of permissions and limits when attached to a role_subject pair.

On to the next use case!

Thanks.

--

Jonathan Keller

Application Architect - Administrative IT

On Jan 14, 2021, at 6:36 PM, Black, Carey M. <> wrote:

Jonathan,

Mostly “what Chris said”. But here are a few more comments/thoughts.

You did not mention what version of Grouper you are running.

                I hope it is at least a container based version.  (2.4+?)

                Moving from container N to N+1 has been mostly trivial. ( Testing always wise and suggested. 😊 )


As far as your data model goes I think you could go either way with the solution. And I suspect that the “how do you consume/use the data” will likely add clarity to the choice.

 

IMO:
   Grouper Permission objects are designed for RBAC and does support “limits”. ( on the Role or the member as I recall .)

   “Limits” can be extended. ( requires code ) So you can create other kinds of limits too.

   Your application is BEST consuming them via “real time WebService calls” back to Grouper. IDK. Maybe that is fine for you. It also means you also need to invest in the Grouper WS servers to always be up and performant enough for your application demands too. 
   They are also not the most obvious to create/configure in the UI. It can be done. And it is a UI designed for RBAC and limits. But your users will still likely need training on the UI.

                I have often considered trying to work up an “permissions example” on the Grouper Demo Server ( https://grouperdemo.internet2.edu/ ) . But I have not got around to that yet.
                Using the Demo server might be a good way to “try stuff out” and “ask others to look at stuff” too. 😊 It is a common resource and could be useful for detailed things like this. 😊

                It also can be useful because you can use Social identities to try things out from different user’s privileged to the Grouper objects too.

 

 

 

If you need to “provision/sync the RBAC with limits” ( via out bound message/Change Log Consumer/Provisioner Framework/… from grouper) to the target application then the work to convert Permissions objects into the target system may be similar to a full “custom Attribute Framework based” design too.

 

 

As far as: “But, the method for getting into the attributes and assigning them makes it feel like that is not really what they were designed for”.

                I would not go so far as “not really … designed”. Rather I think the UI for the Attribute Framework is more generic and “Grouper Admin/Poweruser” focused and really has very little “average user polish”.

                You are also free to use the Grouper WS as a “back end API” to your own UI application too. ( If you would rather do that work than to tech users how to use the Grouper UI. ) Most, or all?, of the WS calls support an “actAs” value that can allow your application to “talk to Grouper on behalf of other users” too.

                Or you could try to improve the UI for all Grouper users by contributing back to the project too. 😊 Just saying it is a possibility. 😊

 

HTH.

-- 

Carey Matthew 

 

From: <> on behalf of Jonathan Keller <>
Reply-To: Jonathan Keller <>
Date: Thursday, January 14, 2021 at 7:35 PM
To: "Hyzer, Chris" <>
Cc: "" <>
Subject: Re: [grouper-users] Structuring Scoped Roles in Grouper

 

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.

 

<image001.png>

--

Jonathan Keller

Application Architect - Administrative IT

<image002.png>

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>