Shibboleth Developers

[Bart Kerver <>]

--
---
Bart Kerver

SURFnet - dep. Middleware Services
phone : +31 (0)30 2 305 373
fax   : +31 (0)30 2 305 329
web   : http://www.surfnet.nl/

--- Begin Message ---

• From: Klaas Wierenga <>
• To: "David L. Wasley" <>
• Cc: Bart Kerver <>,
• Subject: Re: [Fwd: A Case for Shibboleth and PKI]
• Date: Thu, 06 May 2004 19:23:10 +0200

Hi David,

My colleague Bart Kerver forwarded me your e-mail. Please find below my comments. (please cc: me as I'm not on the Shib-dev list)

Attached is a document that describes a case in which I think PKI identity certs bring extra value to Shibboleth. The case was brought to my attention by David Walker as a result of conversations with our campuses who are implementing Shib.

Let me start with stating that I totally agree with your assumption that the network access use case for federated identities is indeed a very important one.
In fact, in the Netherlands we have precisely set up an infrastructure like that, called EduRoam (see http://www.surfnet.nl/innovatie/wlan). This infrastructure is based on 802.1X combined with a RADIUS-hierarchy consisting of a toplevel RADIUS-server run by SURFnet to which all institutions connect their institution RADIUS-servers. User-accounts are of the form , user credentials of a visitor are proxied to the RADIUS-server of the home institution of that user via this hierarchy. Also on a European scale we have expanded this infrastructure to include now a number of other european countries. So far we have not integrated this infrastructure with existing infrastructures like Shib.

I'd love to know if the proposal makes sense or ... ;-)

Also, would someone with 802.1x knowledge expand upon whether there is a relevant layer 2 issue to be considered? I'm sure I don't have that right.

I guess that would be me ;-)

Let me sketch what I have in mind for combining application and network access. In SURFnet's case application access is currently handled by A-Select instead of Shib, but that doesn't matter for the general principle.

I believe network access should be handled at layer 2, all solutions I have seen at layer 3 either are very hard to make secure (web-based captive portals) or hard to scale for guest use (VPN-based solutions). Therefore we selected 802.1X, also because new network access mechanisms like 802.11i build on this.
The basic operation is as follows: a user presents its credentials to the access point, the access point forwards them to a RADIUS-server in the backend (that in turn may want to proxy them further towards the home institution of the user). The RADIUS-server verifies the credentials against some backend (LDAP, SQL, ....). There are various mechanisms to transport these credentials, the most notable being EAP-TLS (using server and client certificates to provide mutual authentication of client and home authentication server) and EAP-TTLS and PEAP (that both use server certificates to verify the identity of the home authentication server and then set up a TLS tunnel to this server to safely transmit the actual user credentials).

I see 3 basic ways how this could interwork with Shib:

1) build some kind of tricky transport to transport web-traffic over these authentication paths.

This is imnsho a rather clumsy approach. The only reasons I can think of to do this would be that Shib is web-based and there are no other interfaces to it or that you want to use an authentication method that requires a direct web-connection to the authentication server (like in the Netherlands to the Internet banking page that we can use to authenticate users via their bank card)

2) Give Shib a RADIUS-interface or make existing RADIUS-servers talk to a Shib backend and use the Shib infrastructure to verify the user credentials. This way the access point can talk directly to Shib via the RADIUS-protocol or via 1 intermediary RADIUS-server.

3) Make existing RADIUS-servers talk to a Shib backend and use Shib to verify the user credentials. User credentials then first travel through the RADIUS-hierarchy towards the home RADIUS-server that verifies the credentials against its Shib backend.

I have currently no strong preference for one of the latter two approaches. The second one is cleaner but further from basic Shib operation. The first one heavily integrates into Shib but is more complex to set up.

I'm curious to find out what you think about this.

Regards,

Klaas Wierenga
SURFnet Middleware Services




--- End Message ---