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

[Dick Visser <visser AT terena.org>]

Hi guys


On 2 April 2014 17:06, Lukas Hämmerle <lukas.haemmerle AT switch.ch> wrote:

> Looking at the example of connect.sunet.se. Leif stated that this
> information is needed about a user:
> * name
> * email address
> * unique identifier
> * affiliation
>
> To get this information a SP somehow has to express these needs.
> So, let's have a closer look at these:
>
> * Email address
> I think we can agree that the mail attribute probably is not a critical
> attribute in this context as it is pretty standard and used in all
> federations. So, declare RequestedAttribute for mail with
> isRequired="true" and things should be pretty clear to anybody what is
> required and what should be released.
> The only issues I could think of in the case of mail are:
> - Organisations releasing multiple values for the mail attributes
>   Don't think this is very common as most applications probably could
>   not handle multiple email addresses
> - Value contains not organisation mail address but private (read
>   Gmail, Hotmail, ..) address.
>   Well, probably not something the service has to care about as long
>   as the mail address still works and the user can receive mails
>   via this address.
>
> * Name
>   Some federations support displayName, others givenName and surname,
>   others (multi-valued) commonName.
>   I would argue here that if the application really *requires* the name
>   of a user, that it should list basically displayName, givenName,
>   surname and commonName als *required* attributes. I would assume
>   that all these attributes contain the same information value, so
>   an organisation does not release more information if it releases
>   displayName, surname and givenName in most cases. And even if, an
>   organisation that is not happy with that, could still limit
>   the release so that for example only displayName is released.
>   As long as there is some name in one of these attributes that
>   somehow is related to the user, why should an application really
>   care? These names are probably in most cases just used to show
>   something more beautiful than "cshu23sd98324rouh" (e.g. an ePTID)
>   in the Adobe Connect Users list.
>   In the end the application then has to - as Leif suggested - act
>   defensive, which in this case means it somehow has to define a
>   priority in which attributes are used (e.g. "if display name
>   is available use that, otherwise use given name and surname if both
>   are available, otherwise the first value of common name, otherwise
>   display error message")
>
> * Affiliation
>   Basically the same as above. Same information in scoped
>   and unscoped affiliation value. So, if the application requires it,
>   list both as required.
>   What's the difference between "staff" and "staff AT switch.ch"
>   assuming that is pretty obvious that in the first case that value
>   was released by SWITCH when the SP knows it comes from an IdP with
>   entityID https://aai-logon.switch.ch/idp (which obviously
>   includes the scope "switch.ch").
>
> * UniqueID
>   This is a bit trickier as the ePTID probably contains less information
>   than the ePPN because it is targeted (different for each SP). So,
>   declaring both of them as required will result in slightly different
>   data about the user. Then again, if the service also requires and
>   gets an email address, what is the use/benefit of using the ePTID?
>   Having an email address from a user (or to some extent his name)
>   makes it relatively easy to identify this user across different
>   services and gone is one of the major advantages (from a privacy
>   point of view) of the ePTID.
>   What the application could do in this case is to store both, ePPN
>   and ePTID or one of these values that is available. This would
>   allow identifying the user both ways, which probably is good for the
>   user and the application operator.


At TERENA we have had this very problem, the main reason is that our
SP Proxy is connected so many IdPs that there really is no common
ground. What we ended up doing is almost exactly what Lukas describes
above.
In our case this is implemented in the form of an AuthProc filter for
SimpleSAMLphp, see attached.

I'm a supporter of a single name field, but many colleagues
require/insist separate first/last name because they think it'll help
in sorting (sorting and order seem super important for some reason).
So I adapted it to the local flavor. I guess it is largely determined
by the country you're in.

Pseudo code:

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"

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

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 ;-)

Anyway.
This authproc will always yield *some* values, so the downstream SP
won't barf over missing attributes.
Some of you have sometimes shown up as "first_name last_name
<invalid_email_needs_updating>" on some of our SPs that hang off our
proxy. Now you now know why: your IdP didn't send enough attributes.
Most of our SPs allow users to edit those values, so it's only an
issue when user log in initially.
It does allow for abuse, but we can fix everything.


For UniqueID we have created another AuthProc filter called smartAttributes:

"A filter to add an identifier attribute, based on the first non-empty
attribute from a given list of attribute names. This is useful when
there are multiple SAML IdPs configured, and there is no common
identifier among them. For example some IdPs send
eduPersonPrincipalName, while others send eduPersonTargetedID. If any
of the social networks are configured as an authsource, they will send
yet another identifier."

It has been accepted into SimpleSAMLphp last year:
https://simplesamlphp.org/docs/stable/smartattributes:smartattributes


THnaks!!!!



-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands

Attachment: BasicAttributes.php
Description: application/httpd-php