Grouper Users - Open Discussion List

[Chris Hyzer <>]

I think what would help is if the loader had a dry-run feature in GSH so you could try a config and see how it goes without it going crazy all over the registry.  If we had that, I wonder if we should default to not be restrictive.  If someone uses the default settings, then decides they need to open things up, they will need to carefully look at all jobs to reconfigure the group name so it is not moved to a different folder and provision the groups again in the wrong spot...  if anyone follows this and has an opinion let me know and maybe we can discuss in the dev call tomorrow.

Thanks,
Chris

---

From: Chris Hyzer
Sent: Tuesday, June 05, 2012 5:34 PM
To: Gagné Sébastien;
Subject: RE: Loader LDAP - Group name _expression_

Yeah, in 2.1.1 I added options to make this more flexible…

 

https://bugs.internet2.edu/jira/browse/GRP-803

 

If you want this in 2.1.0 you could add this to the grouper-loader.properties:

 

# by default the top folder for an ldap group of groups is the folder where the config group lives.

# set to false if you want to be able to provision groups to anywhere

loader.ldap.requireTopStemAsStemFromConfigGroup = true

 

# if you dont specify a groupNameExpression, groups will be loaded into this folder

# if this property doesnt exist, it will be groups:    if it is blank, then there is no top level folder

# e.g. loader:groups

loader.ldap.defaultGroupFolder = groups:

 

Change the first one to false, and blank out the second one.  Then I think just leave the group name _expression_ attribute blank and it will just work…

 

You need to merge the attached file with the source in grouper, and rebuild the grouper jar.  If you want me to send you a new fast.jar with this in there I can…

 

Thanks,

Chris

 

From: Gagné Sébastien [mailto:]
Sent: Tuesday, June 05, 2012 4:04 PM
To: Chris Hyzer;
Subject: RE: Loader LDAP - Group name _expression_

 

Argh! I had tried this syntax, but I just figured that my method was private! (and I was using dn instead of distinguishedName at that time)

 

One last thing, is there some way to create the groups/stems outside of top stem ? I thought giving the full group name in the _expression_ would bypass this but apparently not…

 

If it cannot by configured in some way (that would be the best), I’m thinking that maybe I could use the pre-job hook to manually create the group before the run.

(I think I saw it somewhere in the code, but can’t seem to find it now)

 

I thought I could place the group in the Root, but it doesn’t allow me to. So I might have to place it in the baseStem and be sure not to include it in the group name I’m building.

 

Thanks

 

De : Chris Hyzer []
Envoyé : 5 juin 2012 15:33
À : Gagné Sébastien;
Objet : RE: Loader LDAP - Group name _expression_

 

Argh!  Im really sorry, Im looking at the doc test cases:

 

https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader+LDAP#Grouper-LoaderLDAP-LDAPGROUPLISTtestcase

 

I misread the Java source, the correct syntax is:

 

groups:${loaderLdapElUtils.convertDnToSubPath(groupAttributes['dn'], null, null)}

 

if you just want the dn in your case, try this:

 

${udemLoaderElUtils.convertDnToGroupName(groupAttributes['dn'])}

 

You probably get access to other group attributes as well (cn, etc)

 

I verified this works:

 

Note, I guess the top stem is always the stem where the group is which controls the job… hmmm

 

 

grouperSession = GrouperSession.startRootSession();

group = new GroupSave(grouperSession).assignName("anotherStem:groupListLdapGroup").assignCreateParentStemsIfNotExist(true).save();

attributeAssign = group.getAttributeDelegate().assignAttribute(LoaderLdapUtils.grouperLoaderLdapAttributeDefName()).getAttributeAssign();

attributeAssign = group.getAttributeDelegate().retrieveAssignment(null, LoaderLdapUtils.grouperLoaderLdapAttributeDefName(), false, true);

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapTypeName(), "LDAP_GROUP_LIST");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapFilterName(), "(|(cn=test:testGroup)(cn=test:ldaptesting:test1))");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapQuartzCronName(), "0 * * * * ?");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapSearchDnName(), "ou=groups");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapServerIdName(), "personLdap");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapSourceIdName(), "pennperson");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapSubjectAttributeName(), "hasMember");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapSubjectIdTypeName(), "subjectIdentifier");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapExtraAttributesName(), "cn");

attributeAssign.getAttributeValueDelegate().assignValue(LoaderLdapUtils.grouperLoaderLdapGroupNameExpressionName(), "groups:${loaderLdapElUtils.convertDnToSubPath(groupAttributes['dn'], null, null)}");

group = GroupFinder.findByName(grouperSession, "anotherStem:groupListLdapGroup");

loaderRunOneJob(group);

getGroups("anotherStem")

 

group: name='anotherStem:groups:edu:upenn:groups:test:testGroup' displayName='anotherStem:groups:edu:upenn:groups:test:testGroup' uuid='e4521d491c3d440f9bd61805625d6d7c'

group: name='anotherStem:groups:edu:upenn:groups:test:ldapTesting:test1' displayName='anotherStem:groups:edu:upenn:groups:test:ldapTesting:test1' uuid='eaad5bd7062d453aa8c0acfbe64d14ce'

group: name='anotherStem:groupListLdapGroup' displayName='anotherStem:groupListLdapGroup' uuid='f5dd6ed32a9b4c8ea86b352f945e5110'

 

getMembers("anotherStem:groups:edu:upenn:groups:test:testGroup");

member: id='12345678' type='person' source='pennperson' uuid='09dd1b2226ae4452bef5213cd2073951'

member: id='22345678' type='person' source='pennperson' uuid='13801a6e1c564ce0b79e90fcfd36f17e'

member: id='44567890' type='person' source='pennperson' uuid='4dc08acb1efa4934b6955dcf430a8479'

member: id='33456789' type='person' source='pennperson' uuid='57f6c27766fd4f6f83f5942612905ff5'

 

getMembers("anotherStem:groups:edu:upenn:groups:test:ldapTesting:test1");

 

member: id='10000000' type='person' source='pennperson' uuid='4d8d3fa5e8324c6690b7562fa0245dba'

 

 

 

 

I updated some of the docs to reflect this

 

Thanks,

Chris

 

 

From: Gagné Sébastien
Sent: Tuesday, June 05, 2012 8:37 AM
To: Chris Hyzer;
Subject: RE: Loader LDAP - Group name _expression_

 

Thanks, but I tried it again and there’s still a problem :

 

LDAP extra attributes = distinguishedName,dn,cn

LDAP group name _expression_ = ${udemLoaderElUtils.convertDnToGroupName(distinguishedName)}

 

I get these exceptions :

2012-06-05 08:08:16,266: [main] ERROR GrouperLoaderJob.runJobLdap(537) -  - Error on job: LDAP_GROUP_LIST__etc:confLDAPLoader__e7b97262558b477fab09c0b48f98ed1c

edu.internet2.middleware.grouper.exception.ExpressionLanguageMissingVariableException: variable 'distinguishedName' is not defined in script: 'udemLoaderElUtils.convertDnToGroupName(distinguishedName)',

Problem with ldap conection: personLdap,

Error querying ldap server id: personLdap, searchDn: null, filter: '(objectClass=group)', returning subject attribute: member

[…]

Caused by: org.apache.commons.jexl2.JexlException: ]: 'udemLoaderElUtils.convertDnToGroupName(distinguishedName);' undefined variable distinguishedName

[…]

 

I tried with both distinguishedName, dn, cn and subjectId, and all of them give me an “undefined variable” error.

 

 

De : Chris Hyzer []
Envoyé : 4 juin 2012 17:02
À : Gagné Sébastien;
Objet : RE: Loader LDAP - Group name _expression_

 

Almost got it J

 

${udemLoaderElUtils.convertDnToGroupName(dn)}

 

I think there is a built-in that might do this too, not sure:

 

${loaderLdapElUtils.convertDnToGroupName(dn, null, null)}

 

If you want some of it stripped off, put that as an arg:

 

${loaderLdapElUtils.convertDnToGroupName(dn, “,dc=school,dc=edu”, null)}

 

Let me know if it works

 

Thanks,

Chris

 

From: On Behalf Of Gagné Sébastien
Sent: Monday, June 04, 2012 4:42 PM
To:
Subject: [grouper-users] Loader LDAP - Group name _expression_

 

Hello,

When configuring the Loader LDAP, how can you specify the stem where the LDAP structure will be provisioned ? It seems that the attribute “grouperLoaderLdapGroupNameExpression” is the way to go, but I can’t seem to configure it properly.

 

If I leave it empty, I have my bushy LDAP structure, but not in the right base stem, i.e.

 

groups

- stem1

  - group1

   - stem11

     - group2

- stem2

   - stem21

     - group3

 

What I would like to have is the same thing, but with a different base stem. I tried with :

 

grouperLoaderLdapGroupNameExpression =  udem:${groupAttributes['cn']}

 

But I get a flat structure under etc (the stem where my loaderLdap configuration group is)

etc

  - udem

    - group1

    - group2

    - group3

 

I tried using a custom class which builds the proper bushy group name with the right base stem, but each of the following gives me an error when the loader starts

 

grouperLoaderLdapGroupNameExpression

= ${udemLoaderElUtils.convertDnToGroupName(${groupAttributes['dn']})}

= ${udemLoaderElUtils.convertDnToGroupName(groupAttributes['dn'])}

= ${udemLoaderElUtils.convertDnToGroupName(subjectId)}

= ${udemLoaderElUtils.convertDnToGroupName(['dn'])}

= ${udemLoaderElUtils.convertDnToGroupName('dn')}

= udemLoaderElUtils.convertDnToGroupName(${groupAttributes['dn']})

(this last one does not fail, but does the same thing as the flat structure above, but with a huge prefix (udemLoaderEl…) )

 

 

I successfully used this class with the Subject _expression_ and don’t understand why it doesn’t work with the group name _expression_ :

grouperLoaderLdapSubjectExpression = ${udemLoaderElUtils.convertAdMemberDnToSpecificValue(subjectId)}

 

 

Thank you for you help

 

 

 

 

Sébastien Gagné,     | Analyste en informatique

514-343-6111 x33844  | Université de Montréal,

                     | Pavillon Roger-Gaudry, local X-100-11