Skip to content

Accept mil.no domain as a scope despite failing the public suffix heuristic #15

Closed
iay opened this issue Jan 29, 2021 · 5 comments
Closed
Assignees
Milestone

Comments

@iay
Copy link
Contributor

iay commented Jan 29, 2021

The FEIDE IdP, imported from eduGAIN, claims the mil.no scope on behalf of the Norwegian military. Our current configuration rejects this because it is a public suffix. We'd like to accept it nevertheless.

Background: we reject scopes (plain non-regex scopes and the "literal tail" of regex scopes) which are present in the Public Suffix List, on the reasoning that we should only accept scopes that are capable of being owned and that membership of the PSL is an excellent heuristic for domains which can not be registered. This has always been a heuristic, of course, and as long as we are convinced that a domain is indeed being legitimately used as the name of a security domain then accepting it nevertheless is reasonable. It's a testament to the reasonableness of the heuristic that this is the first time this has come up.

If we want to make an exception for the specific use case (mil.no as a single, non-regex scope) then it's easy to add an "immediately accept this" validator rule in front of the rules that check for PSL membership.

I think making a more general exception would be a mistake: we don't want to accept most -- almost all -- public suffixes (co.uk, etc.) as scopes.

We put a change for this into the UK federation tooling yesterday. I will make a topic branch which (a) cherry-picks that change from upstream for clarity and (b) also makes the same change to the InCommon eduGAIN policy, then hand that over for review.

CC: @nroy @jlasker

@iay iay self-assigned this Jan 29, 2021
@iay
Copy link
Contributor Author

iay commented Jan 29, 2021

I've created the branch described above (15-accept-mil-no). It's untested but goes to show the (lack of) complexity in the proposed change.

As to procedure, if we're going to ship this as a single point fix, what I'd suggest is that I open a new feature branch for a 10.1 release, then open a pull request from 15-accept-mil-no onto that. I think that would pay off later when we're trying to put a real v11 together later on.

@nroy Sound good?

@nroy
Copy link

nroy commented Feb 3, 2021

@iay yes that sounds good, thank you.

@iay iay pinned this issue Feb 15, 2021
@iay
Copy link
Contributor Author

iay commented Feb 15, 2021

I have created a branch dev/v10.1 to act as the target for changes we allocate to the 10.1 release (probably just this one).

@iay
Copy link
Contributor Author

iay commented Apr 18, 2022

The new plan is to implement this as part of the v11 milestone. I will remove the 15-accept-mil-no and dev/v10.1 branches accordingly.

@iay iay added this to the incommon-v11 milestone Apr 18, 2022
@iay
Copy link
Contributor Author

iay commented May 12, 2022

Completed as commit 2ab829d.

@iay iay closed this as completed May 12, 2022
@iay iay unpinned this issue Oct 11, 2022
Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants