10 Feb
2025
10 Feb
'25
9:53 a.m.
On Wed, 5 Feb 2025 at 15:35, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
The authcid is how we convey the authenticating username.
I don't think FAST is tied to any particular
SASL mechanisms? That's why we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I
think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value
to go along with it. Then when doing authentication in the future, this
authcid will select which credential to check against (the FAST token)
instead of using a custom mechanism (the <fast/> tag). This solves one of the two warts in a way that works
with SASL instead of
reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this
is needed at all at this point. A token is a password and thus should work
with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc).
However, in case we want to still allow servers to not implement FAST for
every relevant SASL mechanism they support, I would suggest this change.
Instead of:
The problem is that for some mechanisms and authentication backends,
the server needs to know what kind of credentials are being used
up-front. In an ideal world, I think we would have SASL able to encode
this information.
Specifically, there are two things the server needs to know:
1) The type of credential being used (password, FAST token, bearer token, etc.)
2) In some cases, some identifier of the credential being used (when
the same user has multiple credentials of the same type, common with
tokens)
In many cases (1) can be hackily inferred from the mechanism - e.g.
just assume that SCRAM is always a password, and that HT is always a
FAST token. However I don't think this is a future-proof design, and
there are cases where a mechanism may be useful for multiple
credential types.
For (2) we currently use the SASL2 client id (a single user may have
multiple FAST tokens, because they have multiple devices). Again, it
would be great if SASL had this concept built-in, but it does not
right now.
The FAST protocol was designed the way it was in order to work around
these constraints. I agree that the protocol could be more elegant if
we were to change the SASL layer to accommodate some of its
requirements. But I also think that what we have is fine and
future-proof.
Regards,
Matthew