Grouper Users - Open Discussion List

[Paul Engle <>]

That is essentially the same setup I have for the member attributes I'm
working with. I haven't yet tried to do changelog provisioning, however.

For my purposes, using David Langenberg's earlier suggestion, I've been
investigating the rules framework to get the attributes where I need
them. In doing that, I found it much easier to deal with putting the
attribute on the Member object, rather than on the membership. It does
mean I need a second rule to remove the attribute on membership
deletion, but I can deal with that.

When I was still investigating the membership route, though, I noticed a
difference in behavior when the attribute was added to a membership
object versus an immediate membership object. The former would allow the
attribute to be provisioned with a setup you illustrate, but the latter
would not be seen by the provisioner. I don't know if that's related to
the changelog issues you're seeing or not. Since I abandoned that line
of attack, I never investigated it very thoroughly.

  -paul

On 1/21/2014 4:34 AM, Yoann Delattre wrote:
> 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
>>
>>
> 
> 


-- 
Paul D. Engle              |  Rice University
Sr. Systems Administrator  |  Information Technology - MS119
(713)348-4702              |  PO Box 1892

            |  Houston, TX 77252-1892