Grouper Users - Open Discussion List

["Gettes, Michael" <>]

A combination of approaches is fine by me if I am understanding you properly.

/mrg

On Jul 12, 2017, at 3:05 PM, Black, Carey M. <> wrote:

Michael,

 

In a way, I am want to “use Grouper’s ACL models to control Grouper’s functions and features”.

 

I understand your position. My concern is mostly around this part of your position “shouldn’t be a big deal because”.

 

Let me expand on my suggestions.

                It really is just about absolute control via a data drive model.

                There are other ways to implement the data model. ( And I am very open to those.)

                But I strongly feel that the “right solution” would be to allow any “convention” to be overridden when it make sense to do so. ( AKA: Plan for the exception, because it will happen.)

 

 

 

“RE: I am not a fan of tagging.  With 100K or more groups, this is truly unworkable.  ”

 

Q) What about a group that is maintained by something other than the “Grouper Loader”? How could this tool know that the group is a “no – go for healing”? ( By local policy. )

                Maybe something like a “global exclude group”, or a “Highly restricted/sensitive” group?

                Maybe the group is maintained by a Web Service call from an outside system?

                Maybe the group is maintained by a Message Bus system?

               

Q) What about a group that is maintained by the “Grouper Loader” but local policy would prohibit manual additions? How could this tool know that the group is a “no – go for healing”? ( By local policy. )

                Maybe the org will not tolerate someone being added to the “Staff” group, but would allow adds to the “Student employee” group?

                Maybe the org only allows for those kind of group override changes after a “management review process”? ( For some group(s) )

 

I generally favor the idea of :

    “Tell the software what you want so that it can do what you want it to do.”

 

Over the idea of:

     “Well clearly you understood this convention and would always want what that convention would imply across all of your use cases.”

 

 

 

 

 

As to the specific “scaling concerns”….

 

I indicated that I would be ok with the idea of “auto tagging”. ( For inclusion and/or exclusion too. I was suggesting via rules, but an inheritance model like what attestation does would likely be a better starting point.)

   Think of setting a flag (er… attribute) on a folder that would mark the default for all sub objects (folders/groups).

   The more I think about this I think it should be one Boolean attribute instead of two attributes. ( Currently can an attribute and it’s value be inherited down the folder tree? Hum…. )

 

                Example: A group inherits “grouperOkToDiffUsers=true” from above, but is specifically tagged with “grouperOkToDiffUsers=false” as a “special snowflake” in that structure. So it would be excluded.

                Example2: A group inherits “grouperOkToDiffUsers=false” from above, but is specifically tagged with “grouperOkToDiffUsers=true” as a “special snowflake” in that structure. So it would be included.

 

                This could even be managed ( or just represented via ) “special system groups” that folders/groups can be added/removed from to manage these attributes too.

                                /etc/grouperFunctions/DiffUser ( a composite   /etc/grouperFunctions/DiffUser_include  minus /etc/grouperFunctions/DiffUser_exclude )

 

                                A config setting could be added to “when.group.created.set.DiffUser=[true | false] “ too.

                               

 

If those kinds of tools existed, then *any* “convention” ( used by the UI ) could be used as a general rule (and it can change over time), and local policy could also be honored with explicit “include/exclude” ( group attribute based ) logic too.

 

Just my two cents.

 

--

Carey Matthew 

 

From: Gettes, Michael [] 
Sent: Wednesday, July 12, 2017 11:29 AM
To: Black, Carey M. <>
Cc: Chris Hyzer <>; Bill Thompson <>;
Subject: Re: [grouper-users] Differencing tool with healing capabilities...

 

Sorry for the delayed reply… 

 

I am not a fan of tagging.  With 100K or more groups, this is truly unworkable.  Grouper knows which groups are not viable - if user1 or user2 are an indirect member of the group, don’t show that group (provide a filter mechanism that by default filters out groups of indirect membership - but to debug a problem between 2 users being able to see even the indirect groups will be useful.  Groups with indirect memberships should NOT be able to be healed in this UI.

 

As for loader jobs - grouper knows which groups get generated by loader jobs… group should be tagging groups created by loader jobs so it can know for operations such as this.  These groups should also be able to be filtered as described above.  I will note adding a user to a loader managed group shouldn’t be a big deal because the next time the loader job runs, user1/2 will be left alone (they should be a member) or removed - so healing a loader managed group is temporary until next loader run.  Nonetheless, I appreciate why we wouldn’t want to include groups from loader jobs as part of healing operations.

/mrg

 

On Jul 10, 2017, at 11:45 PM, Black, Carey M. <> wrote:

 

Just some quick thoughts….

 

It might be safer (and ultimately more configurable) if the groups needed to be “tagged” to support this “magic”. That way the local instance needs to be told (configured) what groups are ok for this magic. 

Instead of trying to magically figure out what groups to not do it for. (And rules could be used to auto tag groups by stem too.)

 

It might be possible that some “loader jobs” might be suspect for various reasons in a local environment. ( timing of updates in grouper vs the upstream system, failures to complete the data loads, etc..) So if a local instance wants to include such a group for this kind of manual/scripted comparison, it would be more useful to explicitly need to identify the groups that are “OK” than to try to auto-magically know which groups are “not ok to fix”.

 

 

Maybe via a new attribute named something like: “grouperOkToDiffUsers” ?  ( Assuming the feature is called something like “What’s the diff between two users?” (WTD2U) J

 

 

 

 

The idea could also be extended to dynamically support the idea of WTD2G ( between two groups J ).

                Which might be a nice way to evaluate if two groups are “the same by membership”. ( Seems like a useful function to me. Yea this could be done with two complement composite groups, but a “simple UI” that could allow an admin to “push users” from one group to another could, maybe, be useful if the groups being compared are not composite groups. )

 

 

I kind of have a two column UI in my head.

                Right/Left columns ( with a user or a group value in each column)

                values in the columns would be a “check list” of values that are not in the other list.)

                Arrow buttons to move items from Right to Left, or Left to Right.

                Save/Cancel buttons.

 

                Maybe the UI works for all groups, but the “change/check” buttons are disabled if the groups are not tagged, or if the groups are composite groups?

                                That way you could see the difference and maybe “get a clue” about upstream system data that is driving the difference too?

 

 

OR automatic functions to auto move “Group1 à Group2”, “Group2 à Group1” and maybe even “Group1 ßàGroup2” options to skip the UI lists and “just do it”. ( That would be more like what Michael was asking for. )

 

--

Carey Matthew 

 

From:  [] On Behalf Of Hyzer, Chris
Sent: Monday, July 10, 2017 3:26 PM
To: Gettes, Michael <>; Bill Thompson <>
Cc: 
Subject: RE: [grouper-users] Differencing tool with healing capabilities...

 

Bill, I think grouper needs to keep track of which groups are managed by the loader via internally used attributes to make this happen right?

 

Thanks

Chris

 

From:  [] On Behalf Of Gettes, Michael
Sent: Monday, July 10, 2017 3:22 PM
To: Bill Thompson <>
Cc: 
Subject: Re: [grouper-users] Differencing tool with healing capabilities...

 

Right.  You are absolutely correct.  If grouper can figure all this out and “do the right thing”, that would be outstanding.  I guess this would mean the “healing” capability shouldn’t attempt to fix indirect memberships.  Would that do it?

/mrg

 

On Jul 10, 2017, at 3:17 PM, William G. Thompson, Jr. <> wrote:

 

Just wondering about the scope of the feature and the use case.  If one is following the deployment guide then "fixing/healing" a user who needs access like another user may not necessarily involve manually updating direct members assignments. It could be an issue with upstream data for a reference group, could be an exception/addition to authZ policy, etc.

 

Best,

Bill

 

 

On Mon, Jul 10, 2017 at 3:07 PM, Gettes, Michael <> wrote:

Well, there is no real indication of how a group is being used in grouper - so I’m looking for a tool to do so independent of use.  Now, of course, it would be awesome if grouper could determine the use of a group and show differences and either automatically exclude certain differences (due to policy) or other constraints - but I think this is a wee bit further in the future.  Do I understand you correctly?

/mrg

 

On Jul 10, 2017, at 2:54 PM, William G. Thompson, Jr. <> wrote:

 

Mike, 

 

This would work for ACL-like membership groups, but not for policy driven ones, right?  

 

Best,

Bill

 

 

 

On Mon, Jul 10, 2017 at 2:37 PM, Gettes, Michael <> wrote:

I was thinking (I know, always dangerous)… 

 

If there was a grouper tool to show the differences of group memberships between 2 users and then 2 magic options (make user1 like user2, or make user2 like user1) - this would be a nice way of healing users who should have all the abilities of another.

 

Also, with the above UI tool, give me the option of selecting which groups to “heal” for the 2 users involved with checkboxes on each group.

 

I hope this makes sense and would be useful to others.  Maybe this has already been thunk up and in the hopper for some future development?

 

Thanks for your consideration.

/mrg