That's the big problem Tim - allowing connections to IdPs. A possible  
scenario would be:

- User connects to wireless lan and tries to go to webmail.uni.ac.uk  
(they're home institution's webmail)
- local machine redirects packets to WAYF
- Based on what site the user chooses from the WAYF, the WAYF loads  
that site's metadata and temporarily opens the firewall to those IPs  
(SSO and AA endpoints)
- User then sees their IdP and authenticates
- local machine gets their attributes from the IdP's AA
- based on what attributes come back, local machine opens/closes  
firewall
- they now see webmail.uni.ac.uk

The IdP connections through the firewall are temporary with a time  
limit long enough to allow the completion of a shibb exchange

You can think of it as a 2 stage switch:

1) User flicks limited firewall switch via the WAYF to allow them  
access to their IdP
2) User flicks main firewall switch to allow them to surf freely on  
the wireless - they'd be allowed to "modify the firewall" by  
presenting the firewall with authn and authz via their IdP.

So in effect, the WAYF becomes a trusted firewall switch as it only  
contains federation metadata and can't open the firewall to any old  
site. It's like the parting of the waters. The WAYF opens them up  
just long enough for the user to run across, authenticate and get  
their attributes.

Presenting those attributes to the main firewall switch opens them  
for a longer duration (while the user is onsite).

We're looking at doing this with nothing more than a wee linux box  
running iptables (firewall) and tomcat (Guanxi SP).

Alistair


On 8 Dec 2005, at 14:04, Tim Chown wrote:

> On Thu, Dec 08, 2005 at 01:42:28PM -0000, Sean Mehan wrote:
>> Hi. Yes, interesting. We have been working on this very thing up  
>> at UHI.
>> Basic concept: Using a linux box running ipfilters, it walls off a  
>> subnet
>> to all unknown machines, throws the unknown user out to an IdP,  
>> and upon
>> auth, throws the user's (now known) mac into the filter with a  
>> timeout to
>> allow them through.
>>
>> Is it worthwhile us putting in a blurb to the consultation about  
>> this,
>> Nicole, or would it simply distract?
>>
>> Would other people find this approach useful or not?
>
> I think it would be foolish not to explore this approach further.  One
> possible avenue for discussion might be the next UKERNA WAG  
> meeting, which
> I believe is in Bristol early next year, and/or hold a BoF at  
> Networkshop.
>
> One concern with this approach, is how the authentication session is
> relayed from the user to the home authentication server.   If you  
> take the
> 'restricted VPN' scenario, the idea is to only allow a user to  
> connect to
> a trusted set of VPN servers.  In the UK context that might be 200 HE
> servers, for example, and maintaining an (up to date) firewall  
> configuration
> that only allowed VPN sessions to those hosts for that protocol  
> would be
> 'challenging'... scalability is an issue.
>
> Now, if there were a dynamic way to enable this, the scalability  
> concerns
> would fade.   So the question on the Shib implementation you're  
> proposing is
> how the Linux box knows which auth servers to open connections it can
> legitimately open connections up to (from the client device to the  
> server).
>
> The LIN service proposes network layer authentication, so under  
> 802.1x/WPA,
> the device is essentially authenticating to the network via the local
> authenticator, and any authentication requests are transported via  
> RADIUS
> through the LIN hierarchy (which scales through having a single -  
> perhaps
> virtual - national and trusted RADIUS proxy).
>
> I've copied Mark, in case he's not on this list.
>
> Tim