Restricting federations
Peter Schober
peter.schober at univie.ac.at
Mon Feb 25 07:31:29 EST 2019
* Tim Murphy <tim.murphy at ichec.ie> [2019-02-23 19:21]:
> 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!
eduGAIN does not force such rules upon institutions (eduGAIN has no
direct dealings with institutions and therefore cannot make such
provisions) and Edugate/HEAnet doesn't either, from looking at
https://edugate.heanet.ie/EDUGATE_RULES.pdf
(Cf. section 6, "Identity Assurance". In fact the requirement is that
accounts used in federation are also used to access internal services,
which is already the case for your "external users". So as long as
those are not "shared accounts" and the data is kept current, and the
IDP does not lie about their data, there's nothing here that would
prevent such subjects from using your IDP to access federated
services.)
So why would you prevent such subjects from accessing services if the
service owners would allow them in based on the attributes you'd send?
Such a decision makes no sense.
Furthermore, services within multi-lateral federations (such as
Edugate or ones via the eduGAIN interfederation service) all will be
prepared to provide access based on attributes sent (if they allow
logins from your IDP at all) -- or deny access based on their lack.
So the very use-cases you present here to justify implementing
access control on behalf of SPs /within the IDP/ are the ones where
this is neither necessary nor sensible to do.
-peter
More information about the users
mailing list