Grouper Developers Forum

[Brendan Bellina <>]

This technique is essentially equivalent to using an LDAP service  
account with an attribute in the group object and group members that  
allows the account to see the group and its members but not all groups.

I guess what I missed is this real-time integration between the IdP  
and Grouper. I thought that we were discussing the group memberships  
being stored in LDAP as isMemberOf attributes or entitlements.  My  
mistake.

Brendan

On Sep 4, 2009, at 10:36 AM, Peter Schober wrote:

> Brendan,
>
> * Brendan Bellina 
> <>
>  [2009-09-04 19:18]:
> > I don't see how you can escape some degree of central
> > administration.
>
> I think you need to (re-)read Chris' original proposal on
> grouper-dev. In my own words:
>
> The idea was to add an SP's entityID (or several SP's entityIDs) as
> READER of a group, combined with an SQL view by which an IdP resolves
> only those memberships for the accessing principal where the
> requesting SP's entityID matches the one in the READERS list.
>  This way someone with ADMIN rights on a grouper group can decide
> which SPs will be able to see (part of) the membership(s) of a single
> individial (i.e. the principal that accesses the IdP right now).
>  If an IdP admin then sets up a filter to release any membership info
> to any SP -- because the filtering is effectively done during
> attribute resolving at the SQL level -- the group admin can control
> which SPs will recieve memberships for her groups.
>
> (This assumes that no other source of data will end up encoded as the
> same membership-indicating saml attribute, i.e. only grouper groups
> will be handles this way.)
>
> The drawback mostly seems to be the conflation of data gathering and
> policy application (which hinders transparency, audits, etc)., though
> from some comments linked to in Chris' original email there may also
> be other problems (possible non-deterministic behaviour, IIRC).
> -peter