>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).The authcid is how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that for FAST we put a token id there, which will of course convey the account in question to the server as well (since a token is only valid for a single account).
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)
I think these are basically the same thing. We need to know what credential is being used. If we have an identifier then we will also know the type of that credential based on the id.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
