Restricting federations

[Peter Schober]

* Tim Murphy <tim.murphy at ichec.ie> [2019-02-23 16:21]:
> I'm sure this has been done before, any suggestions are welcome?

The common and scalable model is to leave performing access control to
the resource as the service provider usually is the party that makes
the rules who should be able to access the resource.  I.e., you merely
assert who is staff (or you don't, for non-staff) and the SP then
decides to let staff in but not others.
That works well for thousands of IDPs and SPs, cf. https://edugain.org/

Either way, your IDP's resolver should not be limited to certain
populations as otherwise you can't use it for those services that fall
outside the common set, as you've discovered.
I.e., no filters on affiliation within the data connector(s).

If you're forced to implement access control to a given service within
the IDP on behalf of the *and* this cannot be done by simply not
releasing any attributes to the SP then the IDP has additional tools
to deal with that, mostly around "intercepts":
https://wiki.shibboleth.net/confluence/display/IDP30/ProfileInterceptConfiguration

I'm sure people will have examples to share.

-peter