We have run into a problem trying to implement SVN on our secure cloud platform. Is it possible to pay someone to add modern authentication to TortoiseSVN?
Specifically we wish to use TortoiseSVN client to access VisualSVN Server via Microsoft Azure Application Proxy. This requires TSVN to be conversant in "OAuth 2.0 with OpenID Connect (OIDC)". See https://auth0.com/docs/authenticate/protocols/openid-connect-protocol
You can see the error we get by using TortoiseSVN to open
this test repository https://visualsvn.parabilis-space.com/svn/test/
Error: Repository
moved temporarily to ...Oath2/authorize...
Thank You,
--Jon
--
You received this message because you are subscribed to the Google Groups "TortoiseSVN-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn-dev/4dc5d482-62d0-4c7d-b375-9e1b5e467baan%40googlegroups.com.
Hi Jon and Daniel,Sorry about the late response.We are running TSVN with OpenIDC authenticating with Entra ID (Azure AD), not through the Microsoft Azure Application Proxy though.Server-side, we have Apache httpd as usual but we add the open-source mod_openidc module (instead of basic auth). In addition, some rewrites and other config that allows us to tunnel the session token in basic auth (which TSVN supports).We currently have an installed application that performs the OpenIDC authentication and then inserts the session token in the svn auth cache as a basic authentication. In order to achieve a cleaner implementation that can also work with Microsoft Azure Application Proxy the session token must be sent as a cookie.We would be interested in contributing experience, specifications and server setups if we can get the following stars aligned:- Financial / developer contributions- Subversion core committer interest- TSVN committer interest
We also need to reach consensus in primarily the Subversion project but there is relatively limited amounts of changes that must happen there.- Sending cookie header with session token instead of basic auth.- Capture set-cookie response headers related to refresh of the session cookie.- "svn auth" support for storing session token, very similar to basic auth (cookie name and the token).
- maybe something related to handling redirect to ensure that TSVN can act on that
--
You received this message because you are subscribed to the Google Groups "TortoiseSVN-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn-dev/c1e45328-6ecf-45bc-8065-139668619d31n%40googlegroups.com.
It seems instead of (OAuth 2.0 + OIDC) I should be saying (OpenID Connect), as "OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework."
In my case OpenID Connect (OIDC) is implemented by the middle man (Azure Application Proxy) not the SVN server. However I can see the need during development to authenticate to OIDC on the SVN server. It looks like the SVN server side is already taken care of by this Apache OIDC (OpenID Connect) add on:
OpenID Certified™ OpenID Connect Relying Party
implementation for Apache HTTP Server 2.x
https://github.com/OpenIDC/mod_auth_openidc
Once TSVN can authenticate via any OpenID Connect. It should work with all.
--Jon