Shibboleth Developers

[Scott Cantor <>]

> 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.

I'm not RADIUS literate, but am I mistaken, or does this imply that the
user's password is potentially being given to the local RADIUS proxy and
then forwarded (using TLS or whatever) to the actual home campus RADIUS
server?

Avoiding that (which is equally possible in the web world) is one reason why
Shibboleth was designed.

> 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). 

I think you have to factor in trade-offs, though. You get more security, but
I'm perhaps forced to give you my password. You're happy, but that doesn't
mean I am. Of course, your solution is fine in a PKI world, but Earth
doesn't qualify, yet anyway. ;-)

> 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)

Having a web connection isn't the essential aspect of the use case, having a
*direct* connection to my home authentication server instead of relaying my
credentials through the target is the use case.

> 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.

I don't want my password sent to your access point. If the network precludes
me from accessing my authentication service, then that seems to leave us
with X.509 as a better form of user credential to give to the access point,
and David was essentially proposing some kind of means of using PKI even if
my campus won't issue me a long term certificate (and if I in particular
don't want to manage one as an end-user, which I don't).

Secondarily, he's suggesting that SAML is a potential vehicle for exchanging
attributes about the user so that the access point can decide whether to let
me on the network.

> 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.

Shib per se doesn't ever verify user credentials. Something else does and
then Shibboleth issues a different, short term credential to deliver to the
application in lieu of the user's credentials.

-- Scott