Re: SSO
- From: "Sharad Desai" <ssdesai1@xxxxxxxxx>
- Date: Fri, 18 Jul 2008 08:11:01 -0400
Hi Simon,
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.
I apologize, but can you elaborate on this?
Thanks
On 7/18/08, Simon Wilkinson <simon@xxxxxxxxxx> wrote:
.
On 18 Jul 2008, at 06:57, Russ Allbery wrote:
"Michael B Allen" <ioplex@xxxxxxxxx> 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.
________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos
- Prev by Date: Re: SSO
- Next by Date: Re: SSO
- Previous by thread: Re: SSO
- Next by thread: Re: SSO
- Index(es):
Relevant Pages
|
