SSO

[Sharad Desai]

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 at sxw.org.uk> wrote:
>
>
> 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.
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>