Grouper Users - Open Discussion List

["Crawford, Jeffrey" <>]

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.