A use case on how to deliver group memberships to only specific Shibboleth SPs.
There are many ways to expose Grouper groups to Shibboleth including Exposing Groups Through Shibboleth and the Group Data Connector, but this article details how we specifically do it at the University of Wisconsin-Madison. Our setup involves group membership and group attributes mirrored to read-only copies on a redundant database cluster. These views are also transformed to map our unique virtual identifier up to Grouper groups (separate from the ID we use for Grouper subject source), but you can easily do this method with whatever identifier you are using for your subject source straight out of the box and tied directly to your Grouper Database. I will give examples of both a generic implementation, and the UW-Madison specific implementation below.
In both examples, we want to only deliver group membership for a particular identity to specific Shibboleth SPs. This helps keep the isMemberOf list small for each person and helps prevent an SP from seeing membership in a group that could potentially reveal sensitive information about the person. We do this by setting an attribute on each group listing what SPs by EntityID we want to release this group's membership to. Some SPs may see no groups at all, while others may see many. All depends on if the EntityID for that particular group is set as a value. At the moment, we do not have any groups that are default release to all SPs, but this could easily be implemented by changing the query to look for something like "DEFAULT" in addition to the EntityId as a value for the attribute.
Generic Implementation