Add modern authentication (OAuth 2.0 + OIDC) to TortoiseSVN

96 views
Skip to first unread message

Jon Martin

unread,
Mar 20, 2024, 3:11:28 AMMar 20
to TortoiseSVN-dev

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

Daniel Sahlberg

unread,
Mar 20, 2024, 3:28:13 AMMar 20
to TortoiseSVN-dev
From what I understand, OAuth2 requires both server- and clientside support. So any solution would need to involve both TortoiseSVN and the Subversion project (or VisualSVN). I think it is a great idea but I think some additional development resources would be required to make this happen. Any chance that you (or your company) can get involved in making this happen?

Kind regards,
Daniel

Thomas Åkesson

unread,
Mar 29, 2024, 5:02:33 AMMar 29
to TortoiseSVN-dev
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

When that is in place, I believe it would be possible to have a standalone helper application that performs the authentication and stores it using the "svn auth" subcommand (or equivalent). Alternatively add this support in TSVN which would be the ideal UX.

Best regards,
Thomas Å.


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

Daniel Sahlberg

unread,
Mar 29, 2024, 8:41:21 AMMar 29
to TortoiseSVN-dev
Hi,

fredag 29 mars 2024 kl. 10:02:33 UTC+1 skrev Thomas Åkesson:
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

Hi,

This sounds really interesting. I'm committer in both Subversion and TSVN (and in Serf, if that would be necessary) and as long as things are discussed in the appropriate -dev lists, I can sponsor the commits. Unfortunately I'm not in a position to contribute very much code, simply because of a lack of time.

 

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

These things doesn't sound all that complicated, but should probably be discussed on d...@subversion.apache.org. Would you like to bring this discussion over there?
 
 - maybe something related to handling redirect to ensure that TSVN can act on that

I presume we need to have a notification callback function in Subversion that TSVN can catch to show the authentication webpage, much like any other OAuth2 compatible application does, is this correct?

Pavel Lyalyakin

unread,
Apr 5, 2024, 12:35:37 AMApr 5
to TortoiseSVN-dev
Hello,

If you're looking to use Azure Application Proxy to authenticate to VisualSVN Server with Azure AD credentials, there is another option you might find helpful: Microsoft Entra Kerberos authentication. This option doesn't depend on Azure Application Proxy.

This method should allow Azure AD (Entra ID) users to automatically authenticate with VisualSVN Server using a Kerberos Ticket-Granting Ticket (TGT) they get during logon.

Here's a video that explains how to set it up:


And here are some MS documentation links for more details:
AFAIK, this Entra Kerberos technology is still quite new. Right now, it only works for hybrid identities (synchronized with Microsoft Entra Cloud Sync), although support for cloud-only identities seems to be on the roadmap.

Hope this helps!

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


--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Jon Martin

unread,
Apr 11, 2024, 12:27:42 AMApr 11
to TortoiseSVN-dev
Thomas Å. While we wait on TortoiseSVN  improvements, what is the  "application that performs the OpenIDC authentication" you use on the TortoiseSVN  side? 
Thanks, --Jon

Jon Martin

unread,
Apr 11, 2024, 12:27:54 AMApr 11
to TortoiseSVN-dev

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
Reply all
Reply to author
Forward
0 new messages