Grouper Users - Open Discussion List

["Crawford, Jeffrey" <>]

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.