SSO

[Simon Wilkinson]

On 18 Jul 2008, at 06:57, Russ Allbery wrote:

> "Michael B Allen" <ioplex at gmail.com> writes:
>
>> If you read the whole thread you'd know I'm only talking about the
>> *IntrAnet* scenario. With SPNEGO you do not type in a passwords at  
>> all
>> whereas with WebAuth you might need to.
>
> You're making a bogus comparison.

Russ has pretty much covered the ground here, but I thought I should  
make some comments from our (Cosign based) perspective.

SPNEGO is great in an all Windows environment, where you absolutely  
control every client that's authenticating to your system. It breaks  
down as soon as you add machines which are only loosely under your  
management control. As well as requiring that all clients have a  
properly configured Kerberos client, using SPNEGO with Firefox also  
requires browser configuration, which has to happen for every site  
that users may access, or delegate credentials to, and for every user.

The failure mode for SPNEGO also isn't particularly elegant. If you  
can't do SPNEGO, you can either reject the user, or prompt them for a  
username and password, for every one of your sites that they visit.  
Getting your users used to entering login details every time they  
visit any website is a sure fire way to encourage social engineering  
attacks. Having every server on your network accepting passwords also  
opens you up to attacks on those servers, and severely complicates  
your trust model.

The advantage of a WebSSO system like Cosign or WebAuth is that all  
of this configuration, and fallback, is handled at a single location  
which greatly simplifies management, both of services (which only  
need to know how to talk to your Web SSO system), and clients (which  
only need to be set up to do SPNEGO with your Web SSO login host, if  
at all). Whether you're actually doing _single_ signon at this point  
does rear its head (and in the past, I've been pretty rude about web  
double signon solutions), but with something like either Cosign or  
Webauth you can easily configure other authentication mechanisms in  
front of your web login server, and provide single signon for users  
whose systems support it, without affecting the experience of those  
users who are on systems that don't.

The issue isn't whether _most_ of your clients will support SPNEGO,  
but whether they all will. As soon as you have to add non-SPNEGO  
support, even if that's just to cater for a small number of clients,  
you've lost.

> (Cosign I think requires the ticket cache on
> the central login server, so does introduce the twist of delegation.)

Cosign doesn't require the ticket cache. In fact, if you don't care  
about delegation, you can use Cosign with any authentication source,  
not just Kerberos. Of course, if you don't have a ticket cache, you  
can't delegate credentials to services.

We spent a while looking at different login mechanisms, including  
using purely browser based ones such as kx509 and SPENGO. The only  
way we could see of achieving a reasonable level of both security and  
usability was to deploy a WebSSO solution.

The only fly in the ointment here is that none of the WebSSO  
solutions currently available can handle authenticating POST  
requests, where the user hasn't previously authenticated to the  
service, due to their requirement for redirects. For us, this was a  
small price to pay.

S.