setup question : mschap + perl authentication
Stefan Winter
stefan.winter at restena.lu
Tue Jul 10 14:27:36 CEST 2007
Hi,
> Ah yes, I can see that being a problem, damn this means we can't offer
> any JRS authenticated services other than wireless and wired network
> access. We were planning on a few kiosks dotted around campus... though in
> theory if those Kiosks supported EAP Based login, the tunnel would be
> between the Kiosk and the users Home RADIUS server... Would this be
> acceptable, Or would the fact that we could still theoretically capture the
> users credentials from the login screen be an issue ?
Well, Alan mentioned pGina, and that would sort of fulfill the security
requirements. It's still somewhat borderline, because you are supposed to
enter something on an untrusted computer (mind keyboard sniffers et al).
eduroam was meant as a WLAN infrastructure for *your own* laptop. An exact
border on where to stop calling things eduroam remains to be drawn.
Application-layer authentication is usually something to be taken care of by
an application-level AAI infrastructure.
> > Note also that your problems _can_ be solved quite cleanly,
>
> Shibboleth is in no way clean ! It's an evil necessary... actually the
> Idea is good ,Just the WAYF page is just so horribly cludgy.
> I think the idea of a pre-login form on the authenticated service would
> be a good idea.
> You enter your username string user at domain, this sets a identification
> cookie containing that string and redirects you to your home gateway
> (using a central list of domain->gateway mappings) . You then provide
> your password at your home gateway, which then directs you back to the
> page where you were originally sent from.
> No nasty WAYF pages.
Not working heavily on AAI stuff other than eduroam, I can take it easy here
and just say: *shrug* however you implement it, I don't particularly care.
> > RADIUS. Put your captive portal behind a AAI infrastructure such as
> > Shibboleth. Workflow is...
>
> Were implementing shibboleth already, due to go live summer 2008...
>
> > That way, the user only reveals his credentials to home, not the visited
> > inst. There is a nice paper and prototype impl of this for Shibboleth, I
> > can look up the source if you're interested.
>
> I've read more shibboleth technical documentation than I would care to
> already, but thanks for the offer .
That one actually made me laugh :-) I guess Shibboleth even beats the
legendary 12-pound UNIX manuals.
> No, quite. So this would be a kind of walled garden approach using
> shibboleth for authentication ?
It's not a walled garden: eduroam's sister project eduGAIN (educational GEANT
Authentication Infrastructure) provides tools to cross technology borders,
i.e. if you have a non-Shibboleth Identity Provider for your credentials and
a Shibboleth service, eduGAIN will translate the requests from one language
to another and make them interoperate. So, in short, ANY AAI infrastructure
will do (as long as an eduGAIN adapter ["bridging element"] exists). So, it's
not like you are tied to Shibboleth. We have a cross-federation service
already between PAPI and Shibboleth, A-Select soon to come...
But I guess we're drifting off-topic here... sorry.
Stefan
--
Stefan WINTER
Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de
la Recherche
Ingenieur Forschung & Entwicklung
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: stefan.winter at restena.lu Tel.: +352 424409-1
http://www.restena.lu Fax: +352 422473
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070710/62bb290d/attachment.pgp>
More information about the Freeradius-Users
mailing list