Grouper Developers Forum

[Tom Zeller <>]

I like the incremental provisioning approach that is unfolding :

I think I will write changelog data connectors for each type of
changelog entry that we are interested in, initially membership_add
and membership_delete. These changelog data connectors will be
reasonably straightforward, since they will just return the data that
the changelog entries contain, which are mostly string ids.

So, for example, the ChangeLogMembershipDeleteDataConnector will
return the id of the group and the id of the member that has changed.
Other data connectors can then lookup the corresponding Group and
Member objects using the standard shibboleth attribute resolver
dependency mechanisms. This will provide customization as well as a
reasonably simple default.

New ldappcng code will need to rewrite the attributes returned from
the attribute resolver into SPML <ModifyRequest>s - I have a proof of
concept for this.

Once we complete membership add|delete, we can tackle object renames
and moves, etc.

Hopefully this approach will be good,
TomZ

On Fri, Apr 29, 2011 at 8:10 AM, Tom Zeller 
<>
 wrote:
> No. I think I need the method.
>
> I have the ChangeLogEntry object in the ChangeLogConsumer, but I need
> the ChangeLogDataConnector to query for the same object to calculate
> provisioning via the AttributeResolver - which only consumes a string
> identifier.
>
> If you could add the method, great, otherwise send me a hint ...
>
> On Fri, Apr 29, 2011 at 8:06 AM, Chris Hyzer 
> <>
>  wrote:
>> It's the object you already have right?  Want to just stash in a thread 
>> local or temporary static lookup so we don't have to hit the db for 
>> something we already have?  But yes, we can easily add that method, if you 
>> want to, go for it, or if you want me to, I can do that no problem
>>
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Tom Zeller
>> Sent: Thursday, April 28, 2011 11:01 PM
>> To: Grouper Dev
>> Subject: [grouper-dev] [ldappcng] incremental provisioning : find 
>> ChangeLogEntry by id ?
>>
>> Could it be possible to retrieve a ChangeLogEntry by string id ? while
>> the changeLogEntry is being processed by a ChangeLogConsumer ?
>>
>> e.g. ChangeLogEntry ChangeLogEntryFinder.findById(String changeLogEntryId);
>>
>> Details below :
>>
>> The idea is to represent memberships as distinct objects in the
>> ldappcng configuration :
>>
>>  <object id="group" ... />
>>
>>  <object id="member" ... />
>>
>>  // NEW : distinct membership object
>>  <object id="group-membership">
>>  <identifier ... />
>>  <references name="member" >
>>    <reference toObject="member" ... />
>>  </references>
>>  </object>
>>
>> This distinct membership object would be calculated when the
>> Shibboleth AttributeResolver processes an attribute query whose
>> identifier is the id of a ChangeLogEntry, e.g. changeLogEntry.getId().
>> A ChangeLogDataConnector would return attributes appropriate for the
>> type of ChangeLogEntry. For example, when processing a membership_add
>> or membership_delete changelog entry, it would query for the Group and
>> Member by their ids.
>>
>> Again, the ChangeLogDataConnector would need to query for a
>> ChangeLogEntry by id, hence the original question.
>>
>> So, ldappcng, acting as a ChangeLogConsumer, would calculate the
>> distinct membership objects based on the id of a changelog entry :
>>
>>  public long processChangeLogEntries(List<ChangeLogEntry>
>> changeLogEntryList ...) {
>>   ...
>>   CalcRequest calcRequest = new CalcRequest();
>>   calcRequest.setId(changeLogEntry.getId());
>>   CalcResponse calcResponse = psp.execute(calcRequest);
>>   ...
>>  }
>>
>> The result of the AttributeResolver calculation (the CalcResponse)
>> will be an SPML PSO (provisioned service object) similar to :
>>
>>  <ldappc:pso entityName='group'>
>>    <psoID ID='cn=groupB,ou=testgroups,${base}' targetID='ldap'/>
>>    <capabilityData>
>>      <spmlref:reference typeOfReference='member'>
>>        <spmlref:toPsoID ID='cn=test.subject.1,ou=testpeople,${base}'
>> targetID='ldap'/>
>>      </spmlref:reference>
>>    </capabilityData>
>>  </ldappc:pso>
>>
>> Then, ldappcng, again acting as a ChangeLogConsumer, would execute
>> ModifyRequests which are created based on the PSOs calculated above.
>> For membership_adds, all attributes and references would added, while
>> for membership_deletes, all attributes and references would be
>> deleted.
>>
>> Perhaps an incremental provisioning design.
>>
>> TomZ
>>
>