Grouper Developers Forum

[Tom Barton <>]

GW Brown, Information Systems and Computing wrote:
> > I think a change to a subjectId is needed for audit, but should be
> > transparent to notification. Only grouper needs to know about such a
> > change - presumably if the change has impact in other parts of a site's
> > IAM operation, they'll make corresponding updates using tools other than
> > their group management system.
>
> There is interest in using notifications to prompt provisioning of 
> changed objects. In effect the membership of one or more groups are 
> likely to have changed and would need to be re-provisioned.

I'm not sure I'm following. There's a mapping between subjectId and 
memberId in the grouper_member table. MemberIds belong to groups, 
essentially. When a group membership is being reported, synchronized, 
etc, by a grouper API caller, each member's memberId is used to 
determine its subjectId, and the subject API is used to fetch and 
display or use subject attributes in context.

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.

I'd like to assume that if, for example, a site uses loginIds as 
subjectIds, and they make a change to someone's loginId, they'll reflect 
that change everywhere they can think of, including in group 
representations outside of grouper. They'll also notify grouper about 
the change. I'm still not seeing the dependence between notifying 
grouper of that change and implementing that change in other systems.

Guess I'm just having one of those (increasingly frequent) dense days. 
Sorry! :-)

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