Shibboleth Developers

[Tom Barton <>]

I want to note that my point (1) was only that there must be an 
alternative to a federated solution, not that a federated solution is 
only justified if it works for 100% of users.

The harder issues presented by guest network access have to do with 
sponsorship (who's authorized to bless a guest's access, and how is that 
blessing conveyed to the infrastructure) and the real kicker, how to 
ascertain if that laptop they're carrying is already a threat or may 
become one once subjected to the e-vermin du jur, and how to prevent its 
re-admission to the network once compromised.

If a method to authenticate to them is determined, federated identity 
providers might be trusted to convey a "pre-sponsored" assertion to the 
local infrastructure, which I agree would be a step in the right direction.

Tom

Scott Cantor wrote:

> > Does this problem really need shib? It's a real and common 
> > circumstance, but (1) there must be an alternative to federated 
> > solutions to guest network access, because many guests do not 
> > and will not originate from shibbolized environments (or a common
> > federation, regardless of its architecture),
>
>
> Problem with that argument: it applies to about 95% of the use cases for
> federated identity already. It argues that anything less than a 100%
> identity solution has no value, and I don't think that's true. The point is
> to reduce the exceptions, not eliminate them (which is impossible).

> > and (2), given (1), building 2 solutions to 1 problem, in which one of
> > the solutions always works and 
> > the other does only sometimes, likely means that the solution that 
> > always works will be the only one much used and supported.
>
>
> If there's a solution to authenticating people that's better than "let their
> existing identity provider do it", then it should replace federated
> identity, period. I think the alternative is to one-off them, and that
> doesn't scale, but is completely necessary to deal with the exceptions.