[RADIATOR] Shibboleth authentication for wifi

[Simon Lundström]

My colleague emailed Denis off the list. We have implemented this and it
works well (too well because it makes people not use eduroam) but there
are a few limitations to the solution.

On Mon, 2012-01-16 at 17:25:24 +0200, Heikki Vatiainen wrote:
> On 01/13/2012 03:43 PM, Denis Pavani wrote:
> 
> > My company plans to have a wireless network where authentication 
> > credentials come from a federation using shibboleth.
> > We have in production a cisco wireless controller, and really I was 
> > trying not to bypass it for a different captive portal.
> > Is it possibile to use "authby URL" redirecting creentials to a cgi
> > which provides shibboleth authentication?
> > Does anyone have experience with this?
> 
> I think this model is too straightforward to work. You need to allow
> passthrough for every organisation that participates in the federation.
> The users need to access the authentication web page of their home
> organisation.

Yes and this is possible with parsing the federation metadata, find the
IDPs and automatically create/update an ACL within your wireless
controller.

There are two gotchas/limitations with this step:
* The wireless controller we are using limits the ACL for the walled
garden to 50 (or so, can't remember) entires. So this limits the number
of IDP:s that we can support.
* Creating automatisation for updating the ACL is, IMO, hard but someone
that is better at this might have better luck with it. You can do this
via telnet/ssh&&expect or via the WS SOAP API to the WCS which I don't
think is sanctioned or documented by Cisco (not what we have found
anyway).

> After the authentication the user is redirected back to your login web
> page and the web server sets the environment variables to reflect the
> outcome of user's authentication. That is, you do not get any access of
> credentials you could use to do the login. To actually use this
> information, you would most likely to bypass the controller to utilise
> information from shibboleth.

Well, since we don't trust the RADIUS protocol enough to use our "real"
passwords (we have a seperate identity, and thus password, for using
eduroam) but we still want to be able to verify the user; our workflow
looks like this compared to the one that Heikki described:

1. In the wireless controller use the auth by external-feature and point
this to a Shibbleth protected CGI. We use a Discovery Service/WAYF for
this so that people can choose their home organisation.

2. The success URL users get from their home shibboleth login directs
them back to your web server.

3. The resource pointed by success URL (e.g., CGI script) generates a
user, shared secret and time-based token which is hashed. This token can
later be verified by Radiator.

4. The user is redirected to controller's login page with GET or POST
request type. The request parameters specify the temporary username/password

5. Controller does RADIUS authentication and Radiator verifies the
token.

6. If the authentication is successful, as it always should be at this
point, the controller opens the captive portal. The user has now logged in.

- Simon

---

Simon Lundström
IT Services
Stockholm University