If Jon's analysis is correct (I'm not expert on that stuff either), I think he highlights an important distinction between Web redirect methods like Shibboleth, and LIN/Eduroam.
It's a notable strength of Shibboleth that usernames, passwords (and other credentials for 'stronger' AuthN where required) are *only* shared between the end-user and the host organisation (IdP) with which he already has a personal trust relationship.
I'm sure that LIN when operated by universities will take good care of such credentials. But users should still be concerned if they will be sharing passwords where they shouldn't.
From: Discussion list for Shibboleth developments on behalf of Jon Warbrick
Sent: Fri 21/10/05 12:10
To: [log in to unmask]
Subject: Re: [JISC-SHIBBOLETH] Shibboleth SP for BlueSocket WLAN access products
On Wed, 12 Oct 2005, Tim Chown wrote:
> If the site joins the UKERNA LIN, it can use whatever local backend it
> likes - in this case the Bluesocket device would communicate to a local
> RADIUS server (for local users) or via the national RADIUS proxy to the
> server in the visiting user's home institution.
What your talk yesterday in Edinburgh (for which many thanks, BTW) seemed
to confirm to me is that the current LIN approach seems to be limited to
using passwords and to require users to disclose their password on request
to LIN infrastructure at a site that they are visiting and then to have it
bounced across the country via a network of RADIUS proxies. I'm concerned
that users will not be able to correctly judge when they should and should
not divulge this password (making it vulnerable to theft) nor be able to
evaluate the safety of the forwarding mechanism (though in practise I'd
expect this to be safe). As a result I'm concerned that LIN-based
authentication will be extremely week.
Web-redirect systems, and Shibboleth when using such for the local
authentication, have the advantage that a user should only need to divulge
their password, or other credentials, to a web site run by their home
institution with which they are probably already familiar. It seems to me
that this should result in somewhat stronger authentication.
> It's likely the LIN will push early for 802.1x deployment rather than
I don't yet know enough about 802.1x, but I think I'm about to have to
Web/News Development, Computing Service, University of Cambridge