Grouper Users - Open Discussion List

[Tom Zeller <>]

Sure, if you want spml messages and you want to use the psp, you could
extend the ldap target code to noop write operations. The noop target
will need to support read operations, lookup and search, but could
just log the write operations, add, modify, and delete. Extending the
existing ldap target code to do this should be straightforward.

Full reconciliation spml messages can be produced via a bulkDiff. We
used to support detecting changes since a point in time in the past,
but it was complicated and was dropped. You could query grouper for
objects which have been changed since some point in time, and then run
a diff on each object identifier via the psp.

With a noop target, you could still use real-time provisioning via the
changelog, which would produce spml messages, incrementally.

And, I completely made up the <[bulk] calc | diff | sync /> messages,
so ymmv, although they do wrap spml.

I can comment further, but I am not sure exactly what you are trying
to do, so I'll stop here.

On Mon, Dec 17, 2012 at 6:55 AM, Martin van Es 
<>
 wrote:
> Hi,
>
> I'm currently asked to write a technical design in which grouper is the
> source of provisioning for collaboration shares in University AD/DFS.
> The provisioning route is quite awkward and we will start off by using their
> in-house built relation manangement tool. This tool could easily be modified
> to consume the groups and relations in grouper, but not so well to be a
> provisioning target (if alone because of lack of Java expertise), hence my
> following question:
>
> Is there, other than making a scheduled full export, a way to collect
> time-based incremental provisioning information from Grouper without
> defining a provisioning target? It would be nice to have SPML messages based
> on a question like: show me everything I need to do between an hour ago and
> now. Or, for full reconciliation: everything between 0 and now, which would
> look like the raw export in SPML format.
>
> I could think of a proxy service creating these messages based on a
> stem/group crawl with PIT queries, but a native interface would be a lot
> more robust, I guess? Can anyone elaborate on this idea (crawl+PIT)? Will
> that work? Another idea I had was creating a substitute LDAP target that is
> used to calculate the diff's against? Not so robust if provisioning LDAP or
> relation tool fails. Although import should be resilient for double
> provisioning instructions, missing one could be harmful.
>
>
> Best regards,
> Martin
> --
> If 'but' was any useful, it would be a logic operator