Grouper Developers Forum

[Tom Barton <>]

Chris Hyzer wrote:
> > So, although it's true that a change in subjectId might indeed result
> > in a change in how that Subject's memberships are represented in
> > contexts outside of grouper, it doesn't cause a change to how the
> > Subject's memberships are represented inside grouper.
>
> So we either have subject ID changes flowing:
>
> Source system -> Grouper -> Destination system1
>                  Grouper -> Destination system2
>                  Grouper -> Destination system3
> -or-
>
> Source system -> Grouper
> Source system -> Destination system1
> Source system -> Destination system2
> Source system -> Destination system3
>
> Right?
>
> I think the first way has value because you have probably fewer
> interfaces (since grouper is already talking to the destination
> systems about grouper and membership data).  With the source system
> notifying all the systems that grouper notifies, it will be a lot
> more work and things can get out of sync (i.e. maybe the subjectId
> change in grouper didn't happen successfully, but the subjectId
> change in the destination system [e.g. ldap] did happen successfully,
> then the data in LDAP might not be consistent with grouper.

Things can get out of sync with either approach. And changes to 
subjectId might *not* need to be reflected to groups outside of grouper. 
It depends on each site's identity management practices.

But I guess it doesn't matter. Gary sanely suggests that the audit table 
have a column identifying the object of each change, and notifiers can 
do what they like with that info.

Tom
begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard