Grouper Users - Open Discussion List

["Gettes, Michael" <>]

Ok, this makes more sense.  I read your reply a couple of days ago and I just didn’t get it.

Maybe you can answer the next question I had - I need to write some jexl that will alter variables.  How would I test this without actually invoking grouper loader and PSPNG?  Seems awfully expensive to try something and then fire up the loader to see if it works.  I’d like to construct some variable values and then run the jexl over it to see if it was modified correctly.  I’m not a Java geek so this may be easy but I just need the magical incantation to make it happen.

Ideas?

Thanks!

/mrg

On Jun 4, 2018, at 8:13 PM, Bryan Wooten <> wrote:

Last week my co-work and I spent most of a day trying to figure out Jexl.

The wiki examples were trivial. But we had a use case to load AD groups into Grouper keeping the AD hierarchy. (cn=group1, ou=groups, ou=dept1, ou=majorOrg,dc=school,dc=edu) where all the ou’s become stems/folders and the cn is the group name).

Using a basic LDAP filter like (&(objectclass=group)(cn=hospital*))

So the wiki provided no complete list of methods available to the Java class LoaderLdap.ElUtils.

So we ended searching for the source (LoaderLdap.ElUtils) on Git. And found the exact method needed. It performed as expected! Victory.

Grouper can be made very functional via configuration only, if you know the subtleties of the syntax and relations to the various property files.

I know submissions to the wiki are encouraged, but sometimes I feel a grouper-documentation list could be a benefit. But I have had bad ideas before.

-Bryan

From: <> on behalf of "Gettes, Michael" <>
Date: Monday, June 4, 2018 at 3:46 PM
To: Paul Engle <>
Cc: "" <>, "" <>
Subject: [Ext] Re: [grouper-users] More PSP-NG: custom user attributes in userSearchFilter

******************************************************
WARNING: Stop. Think. Read. This is an external email.
******************************************************

+1 - this is part of where the documentation is lacking a little bit and what led to the questions I had about JEXL in grouper and how it is used.

/mrg

On Jun 4, 2018, at 5:16 PM, Paul Engle <> wrote:

Erik,

  Is this in an LdapGroupProvisioner or an LdapAttributeProvisioner? In the group provisioner, anytime I've needed something from the user entry, I've referenced it as ${ldapUser.getStringValue('foo')}.  I've only used the ${subject} reference in the attribute provisioner. I don't know if that makes a difference or not, or under what contexts each of those objects is available.

  -paul

 

-- 

Paul Engle

Office of Information Technology

713-348-4702

On Mon, Jun 4, 2018 at 3:44 PM Coleman, Erik C <> wrote:

Hello,

 

As a follow-up to my two subject sources scenario, I’m having trouble with custom subject attributes. I now have PSP-NG turned on, and it successfully syncs groups that are set with the provision_to attribute, but when it comes time to add members, I’m getting this error in the logs:

 

grouper-api;grouper_error.log;2018-06-04 19:36:59,091: [uofi_urbana-FullSync-Thread] ERROR Provisioner.evaluateJexlExpression(556) - - Jexl _expression_ samAccountName=${subject.getAttributeValue("samAccountName")} could not be evaluated for subject ''650000001'/'person'/'uofinetid'/null' and group 'null/null' which used variableMap '{userSearchBaseDn=ou=people,dc=ad,dc=uillinois,dc=edu, provisionerType=LdapGroupProvisioner, groupCreationBaseDn=ou=AuthMan,ou=CITES-Services,ou=CITES,ou=Urbana,dc=ad,dc=uillinois,dc=edu, utils=edu.internet2.middleware.grouper.pspng.PspJexlUtils@4f7f3b36, subject='650000001'/'person'/'uofinetid', provisionerName=uofi_urbana, groupSearchBaseDn=ou=AuthMan,ou=CITES-Services,ou=CITES,ou=Urbana,dc=ad,dc=uillinois,dc=edu}'

 

Here’s what I have set in grouper-loader.properties:

 

changeLog.consumer.uofi_urbana.userSearchFilter = samAccountName=${subject.getAttributeValue("samAccountName")}

 

This used to work in our older “pre-TIER” test environment. I’ve considered alternatives:

 

samAccountName=${subject.id}  -- won’t work because we specify subject id using our own uiucEduUIN attribute as specified in the subject.properties.

 

uiucEduUIN=${subject.id} – won’t work because one of my subject sources doesn’t use uiucEduUIN for subject id, it uses samAccountName.

 

Switching to use samAccountName for subject id won’t work, because we have too many people changing netids quite often.

 

A look at my personal subject record in Grouper appears to have everything it’s trying to evaluate:

 

Unique ID:

650000001

 

Name:

Coleman, Erik C

 

Description:

Coleman, Erik C

 

uiuceduuin:        650000001

dn:        CN=ecc,ou=People,dc=ad,dc=uillinois,dc=edu

displayname:     Coleman, Erik C

department:      Technology Services

distinguishedname:              CN=ecc,OU=People,DC=ad,DC=uillinois,DC=edu

samaccountname:          ecc

Member ID:       6fe2e751a0e14e41b896ee6cb8e23e02

Source ID:          uofinetid

Source name:    UOFI AD People

 

Why is the JEXL _expression_ getting an error? What’s the right JEXL syntax for referencing a “custom” attribute in a subject?

 

Thanks!

 

Erik Coleman

University of Illinois at Urbana-Champaign