SSO

[Russ Allbery]

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

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

Well, possessing Kerberos tickets in the domain, at least.  (If you use
Firefox, you don't have to actually be a member of the domain; you can use
a different mechanism for getting Kerberos tickets, such as NIM.)  But
essentially yes.

> And that is the scenario where direct SPNEGO / NTLMSSP solutions are
> going to perform better.

If by "better" you mean "pretty much the same," yes, modulo the
configuration note that I mentioned.

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

Correct.  And if that's easy for you to do for all sites of interest, then
that's great.  It is in some cases and not in others.

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

I'm not sure why you raise mod_auth_kerb when I specifically mentioned
IIS.  It's been an issue for us with IIS and Negotiate-Auth.

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

Correct, and our experience is that, when this happens, the dialog box
presented by the browser often doesn't work correctly and requires that
the user press Enter to get a second password dialog box, depending on
what negotiation the browser tries to do.  The user may also need to enter
a different form of their account name (prefixed with the AD realm, for
instance) depending on the local configuration.

As I say, these issues may be addressable, but I know that they've been
very confusing for users in our environment and have been a definite
negative in doing Negotiate-Auth directly with IIS for us.  I haven't been
directly involved in trying to fix them, but I know that we've deployed
some services using pure Negotiate-Auth on IIS and tried for some time to
address this, finally giving up and just documenting the behavior for our
users.

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

Yes, this is easier with Negotiate-Auth (although only Negotiate-Auth is
needed; your product isn't).  It's standard Apache functionality (using
error handlers for failed authentications) available to any authentication
module, but it doesn't work for authentication modules that never fail,
only redirect the user (WebAuth and Cosign both fit this model).
mod_auth_kerb can fail, letting error handlers do their job.

Shibboleth offers another solution to this problem (lazy sessions) which
has its pluses and minuses compared to using failure handlers.

In brief, the main advantages that something like WebAuth or Cosign offer
is centralizing the handling of the Negotiate-Auth process on a single
system (which may or may not simplify browser configuration depending on
your environment) and a fallback mode that, in the absence of SPNEGO
Negotiate-Auth, is closer to single sign-on than you would get by running
Negotiate-Auth separately on each web server.  What you lose is the
additional complexity of setting up the WebAuth or Cosign infrastructure,
including the need for a central UNIX server, and in the case of WebAuth,
IIS support (making it unsuitable for the problem originally presented on
this thread).

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