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

[Rick van Rein <[e-mail]>]

Hello Russ,

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

No, this has not been tested yet.  Not sure it adds much though; if the
mechanism allows a stateless HTTP server then jumping from one to another
does not matter.  On another note, other layers tend to face this same
problem and seem to solve it by a consistent client/server connection,
and only use the round-robin part as an initiation rite.

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

To do this well, Cyrus SASL leaves a few things to be desired, actually;
namely, a state export/import facility.  This is indeed a conflict that we
are aware of -- SASL is stateful and HTTP is stateless.  This is the reason
that an earlier attempt to HTTP-SASL did not make it.  There is much more
clarity now, with the HTTP Authentication framework being written, and the
answer is bouncing the "s2s" value to allow for a fully stateless server.

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

You are right, this is a new design aspect, and this is why we did not test
on round-robin HTTP servers.  I am not sure if it is so difficult to build
into a simpler library that has collected less history, though.  SASL can
come along, but some implementations are bound to make an easier link to
HTTP than others.

-Rick