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

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

Hi,

not to turn this into a code review but I think many of the practices
employed here are prone to errors or questionable. (Of course the same
goes for Lukas' algorithm describing the same ideas in prose.)

* Dick Visser <visser AT terena.org> [2014-04-18 13:05]:
> First name =
>    'givenName', or
>    first word of 'cn', or
>    first word of 'displayName', or
>    dummy string "first_name"
> 
> Last name =
>   'sn', or
>   last word of 'cn', or
>   last word of 'displayName', or
>   dummy string "last_name"

This doesn't seem to hold even within Central Europe, let alone
globally. E.g. I wonder whether our Hungarian colleagues will issue
cn/displayName in their local custom ("lastname firstname") or using
someone else's ("firstname lastname"). If using local customs (sending
data as it's likely to be stored in directories) obviously you'll be
guessing incorrectly. And let's not even get started about other
naming customs such as the Iberian one(s). :)

> Organisation =
>   'organizationName', or
>   uppercase version of 'schacHomeOrganization' (domain without TLD), or
>   IdP name as displayed on login page, or
>   Uppercase version of email domain without TLD, or
>   Uppercase version of eduPersonPrincipalName domain without TLD, or
>   dummy string "Organisation"
> 
> // This one filtered to only include elements from
> http://www.iso.org/iso/english_country_names_and_code_elements
> Country =
>   'countryName', or
>   TLD of e-mail domain, or
>   TLD of eduPersonTargetedID, or
>   TLD of eduPersonPrincipalName, or
>   'preferredLanguage', or
>   0

That approach has several problems, IMHO. E.g. ISO codes (assuming
3361-1 alpha-2) aren't always equivalent with ccTLDs (e.g. GB != .uk).

And why do you feel "univie.ac" is better (for arbitrary meanings of
"better") than "univie.ac.at"? (And why strip ccTLDs, but not gTLD?)

More importantly, a DNS domain (i.e., the definition of eduPerson
scopes as well as email domain parts and schacHomeOrg values) does not
make an org name. But if you're prepared to accept any kind of string
from attributes meant for different purposes, then why can't you use
those values unmolested/as is?
And eduPersonTargetedId are not scoped and as such don't have a domain
part. (But name qualifiers of the SAML NameID might be based on DNS
domains, maybe you"re referring to that.)

Not saying you cannot or should not do any of the above, justy that
all of that seems rather arbitrary to me (and most of the time the
purpose isn't even clear).

> E-mail =
>   'mail', or
>   dummy string "invalid_email_needs_updating"
> 
> (a pevious version of this filter picked the ePPN if there wasn't a
> 'mail' attribute. That was a wrong assumption by me, I was tricked
> into thinking that something that looks like an e-mail address can be
> used as one ;-)

That might even be true in some cases (I /think/ most US universities
issue ePPNs which are actually deliverable email addresses) but
certainly not universally, so I agree with you reasoning here. Which
seems insonsistent with accepting all the above assumptions as
universal.

> It does allow for abuse, but we can fix everything.

Impersonation, mostly, by making person and organization names
essentially self-asserted (since you'll need to allow people to
correct where the encoded assumtions to not hold).
Which for some forms of collaborative applications seems bad enough.

> For UniqueID we have created another AuthProc filter called smartAttributes:

That is a very useful piece of code and I use it myself. Thank you for
that. It's a bit like the Shibboleth SP's REMOTE_USER abstraction
(freeing application code from having to iterate through all possible
attributes to get an identifier), only that SSP does not allow to
easily include persistent NameIDs (from the assertion's Subject) in
there, IIRC.

Best regards,
-peter