On Tue, 25 Oct 2005, Josh Howlett wrote:
> Another angle: Shibboleth offers a great model for authorisation but
> stinks at authentication (ie. the WAYF). Conversely, RADIUS/802.1X is
> great at authentication, but its authorisation capabilities are
> typically quite clunky compared to Shibb.
This is an appealing 2x2 matrix, but I don't think it stands up under
closer scrutiny.
I assume that the "great model" you're referring to is the fact that the
Shib identity provider in its standard mode sends SAML attribute
statements at authentication time, so a service provider can use those
user attributes for authorization. The applicability of IdP-supplied
attributes for SP access control of course varies greatly depending on the
application. It has been observed that RADIUS can also send arbitrary
information, potentially including user attributes, in its authentication
response. I'm not really sure why it isn't typically used to do this, but
I have to think that it's because the applications it has been used for
haven't found such information useful. In any case it isn't the protocol
but the software that does the processing of it that is "clunky", if it
is, and this presumably reflects the requirements of the users of that
software (ie, service deployers).
Regarding authentication, one of the key benefits of modern authentication
methods is that they permit the separation of user "signon" interaction
from the credential verification and session establishment at the eventual
SP. So I'm not sure what part "stinks". It sounds like you don't like
the WAYF. You'll be glad to know that it is entirely optional and that
most real-world applications don't use it all, instead handling IdP
discovery by configuration at the SP, or by linking from a site at the IdP
organization. In any case, a key aspect of Shib design is to rely on
existing web signon schemes at IdP organizations. I observe that many
organizations have put a great deal of effort into deploying these schemes
over the last few years, and consider them to be the key element in their
institutional authentication system. So if they stink, perhaps they stink
rather less than all the other options.
In particular, when I talk to sites about 802.1x deployment, I hear that
they are proceeding slowly because of client compatibility concerns,
integration with backend authentication services, and in particular a
concern about user experience. This is so even though they appreciate the
benefits it provides in on-the-wireless network security. So I'm not sure
what is great about 802.1x authentication other than it being specifically
designed to work in the network-access use case (hence not relying on
direct connectivity between end-user client and authentication service).
> It's possible that a convergence of 802.1X and Shibb could allow us to
> extract the best from both approaches.
This is certainly true, if we can focus on what the real benefits are.
Unfortunately it's often difficult to separate "what something has
traditionally been used for" from "what it can do".
- RL "Bob"
|