An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

* Tom Scavo <trscavo AT internet2.edu> [2014-11-04 14:58]:
> I suspect that some of those same IdPs support Research & Scholarship
> as well. How does an IdP implement such a complex attribute release
> policy?

IMHO this all really is about the SP and the categories it claims to
carry rightfully, and the processes which lead to those categories
ending up in the SP's metadata, as I hope you'll agree (at least
after this):

Any complexity should not lie with each IDP's configuration, to
enforce entity category defintions (see below for examples), it should
rest with the federation operator doing its job (REFEDS R&S needs to
be assigned/checked by the registrar) or its due dilligence or
post-facto correction (as with GEANT CoCo, which is self-assigned, but
only valid in certain circumstances):

If an SP claims current GEANT CoCo, but is e.g. in the US, it's
misusing the category and this should not propagate. So the SP should
stop claiming that and/or the registrar should stop relaying that
incorrect info, once it has discovered that fact (or it has been
brought to its attention).
Similarly with REFEDS R&S: If an SP is not eligible for R&S from its
purpose, or requests more attributes than R&S allows (which defines an
upper bound), REFEDS R&S must not be assigned to that SP.

So an SP claiming GEANT CoCo /and/ REFEDS R&S must fulfill
requirements from both ECs: It must be in the jurisdictions named by
GEANT CoCo, it must request only attributes needed for operation of
the service, etc. AND its purpose must match the REFEDS R&S defintion
(by/for research/scholarship/collaboration/etc) and it MUST NOT
request more attributes than REFEDS R&S allows (as an upper bound).

The point being, unless incorrect things get recorded in SAML metadata
during registration (or later), IDPs should be able to just release
attributes according to each category definition, without interactions
between those.

> Moreover, how does the Shibboleth IdP software choose between two
> competing policies?

As you know, the Shib IDP evaluates /all/ rules and releases the sum
of all attributes for which release evaluates to true (permit).
In case one rule permits release and another denies, the deny always
wins.

I currently do not spike the entity category support documentation
with deny rules for all attributes known to men that fall outside of
REFEDS R&S, cf.
https://wiki.univie.ac.at/display/federation/Service+Categories

But obviously you /could/ take a more defensive approach to this and
have the IDP deny all attributes outside the REFEDS R&S definition
your IDP supports (in its resolver configuration) as part of your
REFEDS R&S attribute rules. I.e., if policy requirement rule R&S
matches only release R&S attributes and block release of anything
else.
But even that will only protect you againt some of the problems
incorrect categories on SPs' entity descriptors could cause.

I'd rather have that due dilligence done when assigning the category
and checking any requested attributes. If more are requested than R&S
allows, you can't get the REFEDS R&S category. If you're not in EU/EEA
or compatible, you can't get CoCo, and so on.

A common approach on this certainly won't hurt, and I do support
moving this to the main REFEDS list for maximum reach.
-peter