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 <[EMAIL PROTECTED]> wrote: > > > On 18 Jul 2008, at 06:57, Russ Allbery wrote: > > > "Michael B Allen" <[EMAIL PROTECTED]> 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
