Subject Re: Scope spoofing - Scoping Policy Framework?
From Nicole Harris <nicole.harris@xxxxxxxxx>
Date Thu, 12 Nov 2015 10:09:34 +0000

I've been asked to add some details on scopes to the templte metadata
registration practice statement: 
I'm looking for some wording to go in there so thank you :-) 

This is just about documenting what DOES exist and not about dictating
what should be done so if people have examples of how they current craft
scopes or could point me to existing documents that would be grand.  The
scenarios that I think need documenting are:

 - typical mesh IdP
 - typical h&s IdP
 - managed service (e.g. Eduserv, IdP as a service approaches)
 - synthetic scopes (e.g. UK federation schools process)
 - others?

Completely agree that whether any service (whether that be a federation
or edugain) want to enforce specific approaches is another matter.

On 12/11/2015 09:28, Niels van Dijk wrote:
> Hi Kristof,
> In theory I agree with your write-up, however in practice there are
> several issues.
> One scenario we should include is where a proxy could be delivering
> many scopes on behalf of IdPs behind the proxy. THis is common for
> Hub-n-Spoke federations, but also exists in e.g. Uk Access federation
> where some proxies like eduServe exist. Also IdP as a Service
> scenarios could be serving multiple scopes.
> Another scenario is where institutions cold have multiple 'brands'
> attached which are served from the some IdP.
> I am not saying the scenarios above are conflicting with your
> description, its just that whatever we come up with should also fit thes
> e.
> By the way, if we are discussing scope, we should probably also add
> SchacHomeOrganisation into the discussion. We are for example
> expecting the scope to match the SHO.
> Please also find some comments and questions (to you and Tom) inline
> On 12-11-15 01:17, Tom Scavo wrote:
> > Hi Kristof,
> > On Wed, Nov 11, 2015 at 8:29 AM, Kristof Bajnok <bajnokk@xxxxxxx>
> > wrote:
> >>
> >> As far as I know there are no policy requirements in eduGAIN for
> >> registering scopes for IdP and AA entities. IMHO there should be
> >> something. Currently we have this text in `All scopes
> >> used by the Identity Provider MUST be under a DNS domain which is
> >> possessed by the operating organisation.' I know it is not
> >> generic enough, so a better statement should be composed for
> >> eduGAIN.
> > FWIW, I don't think this is an eduGAIN issue. As I see it, eduGAIN
> > is service, not a policy making body.
> eduGAIN is clearly a service with a trust framework attached to it.
> That description could potentially be adapted. I do agree howver it's
> probably better to discuss this in a broader scope liek e.g. REFEDs
> and ten adopt whatever the outcome is of that.
> >> But which document should deal with this issue?
> > Well, I'm not sure it's the right problem to solve. There are
> > three important uses of domains in IdP metadata: entityID, scope,
> > and endpoints. All three are important, I think.
> All are important, but they are rather different things from a trust
> perspective. IdP metadata has 2 roles here:
> - make things discoverable,
> - add trust.
> The entityid and endpoints are part of the technical setup and a
> technical responsibility of the IdP itself. They can be verified in
> and trusted from the IdPs own metadata.
> A claim on scopes is discoverable with the metadata however not
> verifiable from the IdP metadata, it needs a third party.
> >> One possible countermeasure is to run periodic checks on the
> >> metadata aggregate. Its main advantage is that it can be
> >> implemented as part of the eduGAIN operations effort.
> > I don't think the eduGAIN operators are in a position to claim
> > much about a scope in metadata. I don't see how anyone but the
> > metadata registrar can make such claims.
> Indeed, and as such we for example have a registry of all domain names
> an IdP may claim as a scope/SHO. In oractice we have seen very few
> cases where the same technical instance wanted to claim different/
> multiple scopes
> >> However, there is no authoritative source that could determine
> >> whether one entity is entitled to claim the use of a scope or
> >> not. Some fuzzy guess could be made but that guess can be both
> >> false positive or negative.
> > Yes, that's true. When a registrar publishes an IdP entity
> > descriptor, the registrar is implicitly making a claim about the
> > domains in that metadata. If we standardize anything, it should be
> > the essence of that claim.
> >> First, it limits the scope to be a real domain name.
> > That horse has already left the barn, I'm afraid. In the case of
> > eduPersonUniqueId, the scope actually is a DNS domain.
> eduPerson says: "The "scope" portion MUST be the administrative domain
> of the identity system where the identifier was created and assigned. "
> Technically that could be "@idp.local" however we would not allow
> that. Typically we prefer this to be the domain part of the FQDN of
> the institution. But exceptions exist, e.g. when an IdP has outsourced
> its IdP.
> Also, a scope from an NL based IdP could include .nl .com, .org, .edu
> etc. Not an issue perse,  just noting that a per country scenario
> would probably not work.
> >> Second, it has problems with delegation and proxying.
> > Yes, it is well known that scoped attributes do not traverse a
> > gateway or proxy very well. That is "by design," I think.
> Not perse, that is an implementation choice of a SP proxy. I know of
> proxy products that happily retain original scope.
> There is also a potential issue with IdP proxies, see my note above
> Cheers,
> Niels

Nicole Harris
GÉANT - Amsterdam Office
M: +31 (0) 646105395
Skype: harrisnv

Networks • Services • People

Learn more at​