Grouper Users - Open Discussion List

[David Langenberg <>]

Ok, so the deal is the MemberDataConnector does not pickup attributes off the Membership objects.  That is why you're running into issues with attributes based off memberships.  Rather it seems we need a new DataConnector -- MembershipDataConnector -- to handle gathering up attributes applied to memberships. 

I've added https://bugs.internet2.edu/jira/browse/GRP-951 for this.  In both cases, it seems we need some more exhaustive testing of attributes on the various things that the PSP handles as I suspect there's more bugs to find there.

Dave

On Fri, Jan 24, 2014 at 2:28 AM, Yoann Delattre <> wrote:

Hi,

thanks for your answers :-)

My psp.xml :

<psp
  xmlns="http://grouper.internet2.edu/psp"
  xmlns:psp="http://grouper.internet2.edu/psp"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://grouper.internet2.edu/psp classpath:/schema/psp.xsd">

  <!-- Provision a grouper group as an ldap group. -->
  <pso
    id="group"
    authoritative="true"
    allSourceIdentifiersRef="groupNames">

    <!-- The ldap group DN. -->
    <identifier
      ref="groupDn"
      targetId="ldap"
      containerId="${edu.internet2.middleware.psp.groupsBaseDn}" />

    <!-- Identifies ldap group objects which exist on the target by objectClass attribute value. -->
    <identifyingAttribute
      name="objectClass"
      value="${edu.internet2.middleware.psp.groupObjectClass}" />

    <!-- The "old" ldap group DN if a group has been renamed. -->
    <alternateIdentifier ref="groupDnAlternate" />

    <!-- The "old" ldap group DN calculated from group update change log events. -->
    <alternateIdentifier ref="groupDnAlternateChangeLog" />

    <!-- The ldap group "objectClass" attribute. -->
    <attribute
      name="objectClass"
      ref="groupObjectclass" />

    <!-- The ldap group "cn" attribute. -->
    <attribute name="cn" />

    <!-- gidNumber -->
    <!--<attribute name="gidNumber" ref="groupGidNumber" />-->
    <attribute name="gidNumber" />

    <!-- The ldap group "description" attribute. -->
    <attribute
      name="ou"
      ref="groupDescription" />

    <!-- The ldap group "member" attribute. -->
    <references name="uniquemember" >

      <reference
        ref="membersLdap"
        toObject="member" />

      <reference
        ref="membersGsa"
        toObject="group" />


    </references>

  </pso>

  <!-- Do not provision grouper members, but enable lookup. -->
  <pso id="member"
  allSourceIdentifiersRef="memberSubjectIds" >
    <!-- The ldap member DN. -->
    <identifier
      ref="memberDn"
      targetId="ldap"
      containerId="${edu.internet2.middleware.psp.peopleBaseDn}" />

    <!-- Identifies member objects which exist on the target by objectclass attribute value. -->
    <identifyingAttribute
      name="objectclass"
      value="person" />

     <attribute name="textelibre" ref="groupFdv" />

   </pso>

  <!-- Provision a group membership triggered by the grouper change log. -->
  <pso id="groupMembership">

    <!-- The ldap group DN calculated from membership change log events. -->
    <identifier
      ref="changeLogMembershipGroupDn"
      targetId="ldap"
      containerId="${edu.internet2.middleware.psp.groupsBaseDn}" />

    <!-- The ldap group "member" attribute. -->
    <references name="uniquemember">

      <reference
        ref="changeLogMembershipLdapSubjectId"
        toObject="member" />

      <reference
        ref="changeLogMembershipGroupSubjectName"
        toObject="group" />

    </references>

  </pso>

    <!-- Provision a member's membership triggered by the grouper change log. -->
  <pso id="memberMembership">

    <!-- The ldap group DN calculated from membership change log events. -->
    <identifier
      ref="changeLogMembershipMemberDn"
      targetId="ldap"
      containerId="${edu.internet2.middleware.psp.peopleBaseDn}" />

    <attribute name="textelibre" ref="groupFdv" />

  </pso>

</psp>

I found it much easier to deal with putting the
attribute on the Member object

I think like you, but when i try to assign an attribute on a member with Lite UI, i get this exception :

java.lang.RuntimeException: Not expecting attribute assign type: member

Thanks again,
Yoann

Le 21/01/2014 11:34, Yoann Delattre a écrit :

Hi,

I try to provision an LDAP attribute by putting an attribute framework on the membership.
I can read that you already do something like that.

Actually, this is my PSP configuration :

<resolver:DataConnector id="groupFdvTemp" xsi:type="grouper:MemberDataConnector" >
   <grouper:Attribute id="etc:attribute:faits_violence" />
</resolver:DataConnector>

<resolver:AttributeDefinition id="groupFdv" xsi:type="ad:Simple" sourceAttributeID="etc:attribute:faits_violence">
  <resolver:Dependency ref="groupFdvTemp" />
</resolver:AttributeDefinition>

It works when i use a gsh command like :

gsh.sh -psp -diff ydelattre2 -entityName member

But not automatically with the PSP ChangeLogDataConnectors.

Can you help me ?

Thanks,
Yoann.

Le 07/01/2014 17:18, Paul Engle a écrit :

Hi all,
   I'm very close to moving forward and upgrading our 1.6.3
infrastructure to 2.1.5. I have the psp configuration mostly where I
need it to be (and it is sooooo much faster). But there is one thing
that I'm trying to do that is failing.

Basically, I've defined an attribute with the new framework, and
assigned that attribute to a group. I'd like the provisioner to be able
to take that attribute value and assign it to a group member's LDAP
object as a custom LDAP attribute. Similar to the way the
memberIsMemberOf attribute is done in the psp-resolver.xml for the
psp-example-grouper-to-openldap example.

The problem I'm running into is that, since this attribute doesn't exist
on all groups (unlike the 'name' attribute for the memberIsMemberOf
example), I get an 'operation not permitted' error when I try to define
the attribute thusly:


<resolver:AttributeDefinition
   id="profileName"
   xsi:type="grouper:Group"
   sourceAttributeID="groups">
   <resolver:Dependency ref="MemberDataConnector" />
   <grouper:Attribute id="etc:attribute:vpn:name" />
</resolver:AttributeDefinition>


Would defining the attribute as a script be the way to go?
Alternatively, should I be thinking about this some other way? I have
successfully gotten the LDAP attribute provisioned by putting the
etc:attribute:vpn:name on the Membership, rather than the group itself,
but that entails many more steps for the end user. (Add person to group,
add attribute to user as a group member, and then assign the value,
using the same value for every group member). Or maybe I'm not
understanding the new attribute framework very well.

   -paul

--
David Langenberg

Identity & Access Management

The University of Chicago