SSO

[Michael B Allen]

On Thu, Jul 17, 2008 at 5:01 PM, Russ Allbery <rra at stanford.edu> wrote:
> "Michael B Allen" <ioplex at gmail.com> writes:
>> 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.

But only if clients are members of the domain. And that is the
scenario where direct SPNEGO / NTLMSSP solutions are going to perform
better.

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

I believe you mean that you have to add something to "IE > Security >
Local intranet" or the "network.negotiate-auth.trusted-uris" in FF?
You do not have to specify each server explicitly. Those configs
accept domain suffixes.

> 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

Of course. You can't have true single sign on if you're not a member
of the service's domain (or a domain the service's authority trusts).

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

This is a little bit of a stretch. It might be true for mod_auth_kerb
but otherwise, it's basically false.

IIS will do NTLMSSP if the client does not want to or cannot do
SPNEGO. If that fails (e.g. because the client is not logged in with
domain credentials) then the browser will pop up a password dialog but
it will still do NTLMSSP with the creds entered. At least if you're
using IWA it will. Of course IIS to do BASIC but you have to configure
it that way and we're not talking about that.

In our Plexcel product, we provide a script level API which provides a
major advantage over IIS, WebAuth, mod_auth_kerb or anything else that
intercepts requests. So with Plexcel, if the client cannot do SPNEGO,
the script can decide what to do which is usually to redirect the user
to an SSL protected HTML login form where they then use Plexcel's API
again to do a Kerberos 5 login. In either case you end up with a TGT
for talking to other services (provided the service is permitted to
delegate).

WebAuth and Cosign are good solutions when you have disparate networks
where some clients may only support cookies and nothing else. But for
an IntrAnet environment where clients are logged into a domain 90% of
the time, the performance and flexibility of direct SPNEGO / NTLMSSP
is almost always going to be a better solution.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/