On 7/20/2025 2:55 AM, Branko Čibej wrote:
[please do not top-post]
On 19. 7. 25 23:50, Peter Balogh wrote:
Hi,
So you’re generally you have no objection to the idea, that I
recreate the whole Basic auth implementation in svn to support a
custom Basic+OTP auth scheme?
Why are you asking about Subversion here? That's another mailing list,
you should discuss that there.
The point of multi-factor authorisation is that each identifying
factor comes from a different place. Some Basic+OTP authentication
scheme isn't MFA, and the client will have to keep sending the same
info (possibly with an updated OTP token) on every request. That would
probably involve using some kind of bearer token. I think the place to
start is here: https://www.rfc-editor.org/rfc/rfc9110, section 11, and
design a scheme that at the very least does not require sending the
username+password on every request. the Authentication-Info response
header (11.6.3) may turn out to be useful here. And at that point it
might make sense to look closely at OAuth2 again. Who knows, maybe it
can be made to work without requiring a browser. -- Brane
On Thu, Jul 17, 2025, at 15:05, Branko Čibej wrote:
On 14. 7. 25 01:01, Peter Balogh wrote:
Hi,
I think I've just run into this,
Here's the current flow:
1st request without auth gets a 401 response with WWW-Authenticate:
Digest header
2nd request sent with Authorization header gets a WWW-Authenticate:
MFA headaer
3rd request is sent with OTP, but this goes without Authorization:
Digest
In my current implementation the user's password is rerequested, and
everything works fine after that, but I'm having trouble fixing this
As I already wrote elsewhere, Serf handles only one authentication
method per realm. And that's correct, because it turns out that the RFC
requires it to be so.
I can probably add an auth method that does both Basic+OTP, but it'd
probably mean code duplication, or calling the Basic auth method
functions from the new method,
Not without hacking Serf's internals directly. The user-defined-authn
code doesn't give you access to those, on purpose.
but these feel wrong
Any pointers, how to move this forward?
Best regards,
Peter
On 2025. 06. 14. 21:23, Branko Čibej wrote:
Hi all,
I've been digging into Serf's support for various authentication
schemes and I notices something that looks like a bit of a
limitation.
Unless I'm much mistaken, there's space for only one authentication
baton in Serf's context. It would seem that this is rather a blocker
for implementing multi-factor authentication flows, for example,
Basic + OTP, where the server would first require basic credentials
and then, if those were correct, go on to issue an OTP challenge.
It seems to me that a simple solution for that would be to store an
authn baton per scheme, but I know on the close order of nothing
about the possible side effects.
Yeah, I'm starting small, I have no wish to implement OAuth2 flow any
time soon. Still, a bit of insight from the knowledgeable would be
welcome.
-- Brane
Hi,
I wanted to give a quick update of my progress in the last couple
months, partially to share the current plan for feedback, and partially
to have a written log of how I got to the server side of MFA.
The initial idea was that after a successful Basic / Digest auth
request, the server would still return a 401, but with a different Auth
method
The current svn/serf implementation poses a problem, because after the
auth response, in the subsequent requests, the Authorization header will
not be presented, as that auth method did not succeed
That makes properly setting the user on the server side a difficult task.
Initially I tried using mod rewrite, but I have not found a way to set a
username that way
I've tried implementing an AuthBasicProvider script, but that doesn't
trigger in case there's no Authorization header
I've finally found mod_lua, and LuaHookAccessChecker seems to be on the
correct path, so I'll be implementing the MFA server side using this route
Let me know if you have any insight or comments to this approach
Best regards,
Peter
