Grouper Developers Forum

[Peter Schober <>]

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