Restricting federations

[Tim Murphy]

On 23/02/2019 17:29, Peter Schober wrote:
 > * Tim Murphy <tim.murphy at ichec.ie> [2019-02-23 16:21]:
 > 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/

Thanks Peter for your reply.

In an ideal world, yes this would be how it is done. I'm aware of ways 
to define users via attributes e.g. eduPersonAffiliation, and we already 
release these attributes. The issue is that there are external users 
within our LDAP Directory who need access to internal SPs but we only 
wish to allow internal users (staff) access federations e.g. eduGAIN. I 
can't change that decision unfortunately!

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

Yep, exactly.

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

AAF have an example for alumni members:

https://support.aaf.edu.au/support/solutions/articles/19000069529-idp-controlling-access-for-alumni

I'm not sure if it's possible to implement across an entire federation 
though?

Tim.