Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] secure Shibboleth - Grouper integration

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] secure Shibboleth - Grouper integration

Chronological Thread 
  • From: Brendan Bellina <>
  • To: Peter Schober <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] secure Shibboleth - Grouper integration
  • Date: Fri, 04 Sep 2009 10:55:34 -0700

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.


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


* Brendan Bellina
[2009-09-04 19:18]:
I don't see how you can escape some degree of central

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).

Archive powered by MHonArc 2.6.16.

Top of Page