Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

[Russ Allbery <[e-mail]>]

Russ Allbery <[e-mail]> writes:

> I was curious after reading the initial message how this new proposal
> planned to deal with the multi-step authentication negotiation process
> in HTTP.  Maybe that's being discussed on the other list?

I've now looked at the spec, and it looks like this is being handled with
401 or 407 responses plus embedding the server state in the response and
expecting the client to reflect it on subsequent requests.

I think this would work theoretically (at least I don't see why it
wouldn't), but I'm very curious about how widely this has been tested in
HTTP scenarios involving round-robin load-balancing.  Making the client
replay the state provides enough of a theoretical hook to allow moving an
in-progress authentication session from one backend server to another, but
has this been done in practice with Cyrus SASL and similar SASL libraries?
My first reaction is that this is asking a lot of the SASL library on the
server side to be able to reconstitute and continue a halfway-constructed
SASL session that was negotiated by a different server, but maybe that
first reaction is erroneous.

-- 
Russ Allbery ([e-mail])             <https://www.eyrie.org/~eagle/>