SSO

Russ Allbery rra at stanford.edu
Thu Jul 17 17:01:55 EDT 2008


"Michael B Allen" <ioplex at gmail.com> writes:

> For example, you mentioned WebAuth and CoSign. Both of these solutions
> are really targeted for highly heterogeneous environments like
> University networks where the only client requirement is that the
> browser support cookies. So it works on the IntrAnet, the IntErnet, on a
> hostile dormitory network, a kiosk at the airport, ...etc. But if you
> don't have those requirements these solutions do have quite a bit of
> overhead with all the redirecting

This is generally not noticable in practice.  However, what is noticable
is the additional level of complexity from having to run a central login
server.

> and, more important, they do not give you true single-sign-on
> behavior. They're more like "double sign on" because you have to login
> to a central server and they get redirected back to the target site.

Well, no, they're double sign-on because the central server usually has to
prompt you for a password.  But if the central server implements
Negotiate-Auth and the browser speaks it, both WebAuth and Cosign give you
true and complete single sign-on.

> For a strictly IntrAnet environment the WWW-Authenticate: Negotiate or
> NTLMSSP protocols used by IIS, mod_auth_kerb, Plexcel, JCIFS and
> others are the only true *Single* Sign On solutions where the clients
> existing credentials are used to transparently authenticate without
> requiring the user to enter a password.

This is true, but somewhat deceptively so, given that WebAuth and Cosign
can both leverage Negotiate-Auth to extend that single sign-on capability
to all web servers without Negotiate-Auth on each one and (often more of
an issue) without having the user have to bless every server for
Negotiate-Auth authentication.  (They only have to bless the central login
server.)

However, if that configuration issue isn't a concern, simply using
Negotiate-Auth, which is built into IIS, is definitely easier.  It does,
however, require that your clients have a local Kerberos configuration
(members of an AD domain, for example) to get single sign-on and falls
back to essentially basic-auth for each server without it, whereas WebAuth
or Cosign will fall back to a single web authentication and then reuse of
that authentication without having to further enter your password.  The
password prompting behavior from an IIS server to Firefox and similar
browsers is also poor and confusing in our experience, but that may be
fixable.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the Kerberos mailing list