Previously, I tried setting up a more efficient Shibboleth Attribute Authority - one where I could query for a specific attribute value for a specific attribute for a specific user (e.g. does firstname.lastname@example.org have an experimentId attribute with the value 2?). While you can add attribute values to the attribute elements in a SimpleAggregation AttributeResolver query, the IdP rejects the query.
Another Shib-based option would be to develop a plugin that can create attributes from server environment variables (like REMOTE_URI). One could then use the Template and Tranform Attribute Resolvers to create a new NameID attribute for the SimpleAggregation query (something like eppn:https://SERVER_NAME/REMOTE_URI). Then an Attribute Authority could be configured to split the NameID into multiple attributes and use those for a SQL query or LDAP lookup.
That seemed like a bunch of work, so instead I took a look at using Apache’s mod_authnz_ldap on the SP instead. In this scenario, when an unauthenticated user attempts to access a set of experiment results, they are first sent to an IdP (via the embedded discovery service) to authenticate, then mod_authnz_ldap queries a remote LDAP server for attributes (group membership seems to be the easiest model) and determines whether the user has access.