Grouper Users - Open Discussion List

["Crawford, Jeffrey" <>]

Morning,

 

After sleeping on this a bit and reading Bert’s #1 item. It hit me that if we can get pspng to support both the new name and the alternate name *and* add an option for the UI to not check the checkbox to set the alternate name on a move if an alternate name already exists. Then for those of us who use LDAP record markup would have a way to maintain service on a move. And even if it got moved again, unless you specifically check the check box to set the alternate name then the attribute would keep the original name.

 

That way on the first rename/move the alternate name would be set, but on subsequent rename/moves the same alternate name would stay the original group name.

 

I’m guessing that’s the simplest way to do this?

 

Thanks

JEffrey

 

From: <> on behalf of "Crawford, Jeffrey" <>
Reply-To: "Crawford, Jeffrey" <>
Date: Wednesday, June 12, 2019 at 10:49 AM
To: "Bee-Lindgren, Bert" <>, "Hyzer, Chris" <>, "Black, Carey M." <>, Grouper Users <>
Subject: Re: [grouper-users] pspng and naming for reorgs

 

Answering inline (again 😊)

 

From: "Bee-Lindgren, Bert" <>
Date: Wednesday, June 12, 2019 at 8:50 AM
To: "Hyzer, Chris" <>, "Black, Carey M." <>, Grouper Users <>, "Crawford, Jeffrey" <>
Subject: Re: [grouper-users] pspng and naming for reorgs

 

I have a four thoughts...

1. PSPNG could support Alternate Names of groups, either by provisioning both names or by group-nesting the 'real' name into a group object representing the Alternate Name. This would be most useful when you're willing to migrate the place where the application looks and, eventually, delete the Alternate Name. Do folders also have Alternate Names?

Are you saying that the provisioner would/could create two markup attribute values, one with the current name and one with the alternate name? Is there a mechanism that prevents a group id creation if it matches an alternative name? I would be worried that it might hide the problem that a move has occurred but the service still works because of the alt name. Not much in the way of saying, hey you need to fix this service now. Perhaps a warning on move/rename etc that an alternate name is already set and it could have an impact if it’s renamed/moved again.

 

2. As others have said, Provisioned groups are typically written to ldap for applications to look at, and can be flatter than a departmental structure... with some mechanism for disparate app owners to get an app: subfolder where they can manage their groups. Maybe with templates, app:-subfolder creation could be more delegated?

Okay so instead of org:division:subdivision:app:wiki you do app:org:division:app:wiki:subdivision

 

3. Is there perhaps an option to minimize the likely changes to the folder structure by leveraging folder displayNames and using orgid numbers as the real folder names?

I think permission inheritance is the problem, if you move the app to a new subdivision you want new permissions of the subdivision to propagate to that app.

 

4. Folder hierarchies are useful for (at least) two things... making things more browsable and providing locations for access control. Could we create a mechanism for the folders to actually be flat, but 'symlinked' into the current hierarchy of the organization? This could provide both browsability and access control if the virtual/symlinked hierarchy contributed to permissions.

This is interesting, Santa Cruz did something like this with:

org:stuff

provision:app:stuff

 

And then where the “stuff” was constructed to with either embeded group memberships or a composite depending on the need. It requires more setup and may be difficult when you build things with org hierarchy. If I’m understanding it right you would have org:any:number:of:org:stuff:app:wiki:entitlement:admin and you create a app:wiki folder that actually points to org:any:number:of:org:stuff:app:wiki, but you provision from app:wiki:entitlement. And if the org level wiki app moves the symlink stays intact. Then the provisioned name becomes first come first served in the app area.

 

Actually this idea even helps with a different problem, you can have one org hierarchy but symlink it to other areas of grouper, possibly in a way that allows you to augment the original with additional folders and groups in the target (Would need to find a way to make that clear) but if an org level change took place then the symlinked version could get that update, unless a removal would orphan any local groups/folders created.

 

 

Thanks,

  Bert

 

---

From: <> on behalf of Crawford, Jeffrey <>
Sent: Wednesday, June 12, 2019 11:14 AM
To: Hyzer, Chris; Black, Carey M.; Mailing List
Subject: Re: [grouper-users] pspng and naming for reorgs

 

This is really tricky. I’ve responded inline below. My hope is that something like the following would happen with some guidelines, org:itservices:subgroup:app:subgroupwiki:admin and org:itservices:anothergroup:app:otherappwiki:admin. This would be a training issue, however I recognize that pspng probably won’t notice any conflicts in this regard and will just happily clobber the other groups wiki if a group of two people did org:itservices:subgroup:app:wiki:admin and org:itservices:othergroup:app:wiki:admin.

 

<Sigh> there has to be a reasonable way to do this. Is there anything in PSP_NG that can help since this is a single definition? we seem to have a lot of options and I don’t think I understand all of them.

 

Thanks

Jeffrey C.

 

 

From: "Hyzer, Chris" <>
Date: Monday, June 10, 2019 at 12:46 PM
To: "Crawford, Jeffrey" <>, "Black, Carey M." <>, Grouper Users <>
Subject: RE: [grouper-users] pspng and naming for reorgs

 

Four thoughts:

 

1. We re-orged our IT dept and we just left apps where they are and adjusted the privs.  Doesn’t work as well when there are inherited privs at the org level which still exist, but thought I would mention it.  We also changed some friendly names of folders so the old org name isn’t on the UI (but is in the system name so apps don’t break)

I guess there are worse things in the world but I’m trying to avoid this

2. There is the concept of “alternate name” so when you move things they are referenceable from two locations.  This is a confusing concept and Im not sure how PSPNT supports that

This give you one freebee rename 😊 I think the reality is that you would have to have two pspng configs, one with group name and on with group alt name.

3. The GDG did have a high level “app” folder (outside of org folders).  Would require either distribute access to CREATE in the “app” folder, or tickets in to admins when a folder needs to be created

These areas are going to be controlled by us so probably less of an issue

4. The important thing about using the whole namespace is you wont have different branches stepping on toes.  I would be nervous chopping off the root for re-orgs since sub-branches could conflict.  E.g. what happens when two nested app folders both have a “wiki” folder?

I was hoping that the top level org would be the one to have such a folder, but you are right, if two people are given subfolder access to two different folders and they both had wiki:admin then chaos will ensue

 

 

thankss

 

From: <> On Behalf Of Crawford, Jeffrey
Sent: Monday, June 10, 2019 3:30 PM
To: Black, Carey M. <>; Mailing List <>
Subject: Re: [grouper-users] pspng and naming for reorgs

 

Hey Carey,

 

I should have probably prefaced the fact that we are not really using Grouper to manage LDAP groups here (AD or otherwise). We are using the account markup model (ABAC) that is then used by services to understand what service an account should have access to. We use pspng to populate the eduPersonEntitlement attribute. Then various services/application across campus will then read the entitlements to know if the user has access. This entitlement attribute is part of the users record and will inform systems at the time of use what access that account holder should have. This also implies that one group’s eligibility criteria may be used by another application or even many applications

 

For example lets say that anyone who accesses the datacenter VPN must have MFA. Even if they access another application, and a reporting tool is used to make sure anyone who has this access is reviewed by Audit. In Grouper lets say this group is “org:its:sysops:app:vpn:datacenter:user” We now have three applications that are interested in this ABAC based entitlement. If the eduPersonEntitlement is set to something non organizational like “its:vpn:datacenter:user” and three different applications are using it. Then it’s safe to move that group/app to “org:its:networking:accessgrp:app:vpn:datacenter:user” when someone decides it’s time to change who’s responsible for access. If more of the org were to be included and the group is moved, then you have three application that must all coordinate the change, if they even all know about each other. Now if you then think of something like eduPersonEntitlement = “studentsys:slate:entitlement:incoming” and you can imagine the number of application may want to know that entitlement so they can decide if the student should have access to their service or not.

 

With that out of the way 😊 I do find your point intriguing about knowing that access is now responsible by another party. So let’s reflect that in the name. But you also are using GUID of the group in the background in AD so if that group is simply moved it may have less impact in the AD world. The group membership is still intact via GUID so it “doesn’t matter” where it is. And I think groups in AD must be globally unique. So my problem may be very ABAC specific.

 

I think pspng for ABAC is pretty flexible, maybe too much since in my example I’m using regex to find and remove components of the group name. The other thing is that I’m trying to build a culture of actually delegating folders to groups across campus. So far we control up to the division level under org, then we delegate out from that point. For example we’ll control up to the folder after org so “org:soe” and we’ll delegate out “org:soe:it” then it up to the delegate to create “org:soe:it:app:app1:entitlement:someentitlement”

 

You are of course right, in that you have to tailor the Grouper environment to the way you are distributing access.

Jeffrey C.

 

From: <> on behalf of "Black, Carey M." <>
Reply-To: "Black, Carey M." <>
Date: Monday, June 10, 2019 at 10:13 AM
To: "Crawford, Jeffrey" <>, Grouper Users <>
Subject: RE: [grouper-users] pspng and naming for reorgs

 

Jeffery,

 

Unfortunately, I think you are pointing at a convention/design ( limitation ?)  of PSPNG when you said this:

                “We want to provision that to our LDAP (now) but in a way that vpn app might be moved to (somewhere else in LDAP later)”

 

My current understanding of the LDAP placement rules of PSPNG  (and group/user search logic) are based on the “folder structure” in grouper mapping to a single “OU/structure” in LDAP.

I don’t know of a way to break/override that convention at this time. ( Nor would I think you would want to do that. More on that next. )

 

MHO:

                In general, names matter. And normally a lot more than you want them to when something “changes” later that was not expected.

 

                If the AD group is moved (and supported to be moved ) then the “source group” (aka: in grouper) needs to be moved to get the AD group moved.

                That implies that both AD OU’s are modeled in grouper and the user moving the group has enough privs to both folders in grouper and the group in question.

 

                However, that may still break things using “AD groups” because the application using the group is what really matters.

                                The app may or may not be:

                                                DN based,

                                                “CN” based,

                                                                or

                                                GUID based (“happy path”?) .

 

                And the likely hood that all applications behave the same way… just about zero IMHO.

 

 

As I am standing up Grouper to manage AD groups (at the moment).I have negotiated a single OU for grouper to place and manage groups in our AD. ( Yes there is an OU structure in that OU, but that is all under grouper’s control. ) So the idea of moving from one grouper folder to another would be a logical move under the umbrella OU that grouper controls. ( And subject to all of the chaos that might happen in the applications. But I think a move inside the same PSPNG config would actually “move” the group and maintain the GUID. But I am not sure if that would work across PSPNG configs. [ How would they know they are the same “AD” to do a “move of the group”?  ?? ] )

                And FWIW: I am truncating the grouper stem names and letting the groupCreationBaseDn drive the rest of the parent OU structure in my single PSPNG config/setup.

                // not the exact config values

                … .groupCreationBaseDn = OU=GROUPER,DC=XXX,DC=XXX,DC=XXX,DC=XXX,DC=XXX

                … .groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name.replaceFirst("grouper:folders:to:ignore:",""),"cn", "ou")}||cn: ${group.getExtension()}||objectclass: group||objectclass: top

 

 

On the other hand:

                Grouper can have a nested group across those “AD folders”( in grouper) too. So the need to “move” is not really useful unless the application(s) are GUID based. And when you are talking about logical moves across existing organizational boundaries (AKA: Not an org rename, but a actually “let them do this from now on” condition.) then is seems like changing everything in AD (OU, group name, and GUID) would be wise IMHO. And easily done in the short term by including the original grouper group in to the (new) target AD group while the new group (maybe with some “expires membership in 60 days”) takes over payments on managing the memberships in a different contributing sub group.

 

 

Now if you could get your AD team to let you map to the grouper folder to the root OU in AD, then you can reproduce/model all OU’s in the AD. ( But good luck taking that on too. :) )

                Though to be fair, the grouper integration does not need to have write access to the whole AD tree. You may just need to mock in the OU’s and then not let grouper users write to all of them. :) Open up the terminal folders (AKA: OU’s) where grouper can write to AD as appropriate. But I have not tried that approach. Nor do I think it is really any better than the “single OU for grouper” model that I am starting with. Just more complexity and empty folders in grouper IMHO.

 

 

YMMV. Good luck.  I look forward to the wisdom from the rest of the user community on this topic too. ( Maybe I have completely missed some options/designs? )

 

--

Carey Matthew

 

From: <> On Behalf Of Crawford, Jeffrey
Sent: Monday, June 10, 2019 11:59 AM
To: Grouper Users <>
Subject: [grouper-users] pspng and naming for reorgs

 

Morning,

 

Apologies for the Monday morning thought exercise, I’ll try and keep this as short as I can but it’s a complicated subject in my mind.

 

When looking at the Grouper TIER Deployment Guide, good work by the way, I’m left with the conundrum of the Grouper org structure of the groups vs what you want to provision downstream generically. This is specially relevant to us as we are very likely going to be going through a reorg once we hire a CIO type of position. So how can I make an LDAP export rule that applies to applications when that application may change hands. This includes some level of delegation to a department so we are not always in the loop for setting up new services which is what we want.

 

From what I gather the deployment guide would imply we create a vpn group like the following, if we include the major org and any number of suborg folders:

org:itservice:networking:app:vpn:entitlement:eligible

 

We want to provision that to our LDAP but in a way that vpn app might be moved to:

org:itservice:centralaccess:app:vpn:entitlement:eligible

 

On it’s surface you can take away everything up to and including “app” which then leaves you with “vpn:entitlement:eligible” but now imagine you also have:

org:med:it:app:vpn:entitlement:eligible

 

The PSPNG rule would result in the same exact string of “vpn:entitlement:eligible”, So I went back and figured I would also include the first folder after the org and then remove everything to the last “app” string. It would seem the first level org structure would rarely change, but that’s not a guarantee. If they change orgs to this level we may need to be involved as the Grouper service team. Therefore this gives me a regex process and results of:

 

# replaceAll("^org:([^:]+).*:app:(.*)$"), "$1:$2")

org:itservices:networking:app:vpn:entitlement:eligible -> itservices:vpn:entitlement:eligible

org:med:it:app:vpn:entitlement:eligible -> med:vpn:entitlement:eligible

 

The above solution isn’t perfect, you can still have cases where for example someone sets up

org:itservice:networking:app:vpn:entitlement:eligible

org:itservice:networking:datacenter:app:vpn:entitlement:eligible

 

and your right back where you started. Now I hope someone would actually create the last entry as:

org:itservice:networking:app:vpn:datacenter:entitlement:eligible

 

As that would be in line with what the application is doing (datacenter vpn vs generic campus vpn). We can have some structure by perhaps only delegating out from the second folder after the first level org so we would have to be involved with any large level org changes. But we can’t prevent people from creating a bad naming structure  (Some of this is of course education).

 

Of course you could make lots of psp_ng configs in the grouper-loader.properties and assign them individually we’ve done that to some degree. We already have 21 , however I’m looking for something cleaner and I’m not sure what kind of impact having 100’s of psp_ng configs in the loader could be. However this also means we’ll need to be involved with any changes as we will likely need to change some string in the psp_ng config anyway if an app is moved.

 

I’m looking for two things out of this email. Those of you who have given thought to this and implemented something, and to start the conversation of decupling application data from Org structure.

 

Jeffrey C.