Wow - interesting. I don't know anything about TortoiseSVN, but presumably it will 'just work' if svn itself can be fixed up. Daniel - if you move everything to dev, I'll follow there.

Thoughts about TA's post:

1. Why "tunnel the session token in basic auth"? Does he want HTTP
   basic auth /and/ HTTPS mod_openidc_module? How does a session token
   fit in with basic anyway?
2. I don't quite understand the 'svn auth' comments - is Thomas
   suggesting /manually/ recording tokens and cookies?
3. Any solution must have bearer tokens /and/ cookies - but that's
   obvious,  so presumably I've misunderstood the post

On the callback: this has to be caught by a webserver which is initiated by svn, not TSVN, or command-line svn couldn't use OIDC. TSVN doesn't need to know anything about any of this. But, as I said, I know nothing about TSVN so I may be wrong. If TSVN actually makes curl requests to the server, for example, then it would need to know.

Thomas has obviously done a lot of work, but another option is to port GCM. This does exactly what is required, except that it interacts with its own credentials manager and not svn's, and there are hooks from git which need to be replaced. Command-line OAuth2/OIDC would be generically useful, so it would be a pity to do this work just for svn. However, GCM is written in C#, on .NET Core, and I know nothing about C# or the .NET runtime (I do C++/Linux). I think dotnet can be fiddly to get running on Linux (I've only tested GCM on Windows).

Another option is to integrate oidc-agent <>. This has less baggage than GCM, and is written in C. It's straightforward, and well-documented, and is a good place to get some understanding of what command-line OIDC is. I looked at this last month but didn't have the time to go any further. The developer/s are academic ( <>) and, I think, would be interested in this. I have a bit more time now so I'll have another look at this.


On 29/03/2024 15:46, Daniel Sahlberg wrote:
Den fre 29 mars 2024 kl 16:27 skrev EML < <>>:

    Before I do too much work on this, I'd like to do a sanity check.
    Does anyone know of a client which will access a repo over HTTPS,
    with an access/bearer token? This gives SSO and multi-factor
    authentication using OAuth2.

    The repo runs behind Apache httpd, which is using
    mod_auth_openidc. The config file sets 'AuthType openid-connect',
    and 'Require valid-user'. The repos additionally require a
    specific claim to access them ('Require claim x:y:z').

    This all works with git, using Git Credential Manager
    <> (GCM;
    this is a cross-platform .NET Core app).

    Basically, two things need to be done:

    (1) HTTP requests need to specify 'Authorization: Bearer' with an
    access token. If you don't have an access token, something (a
    script, GCM, whatever) has to pop up a browser window and connect
    to an OAuth2 identity provider (IdP). The user then logs in (with
    MFA if configured), and the IdP then redirects back to localhost
    with a token. This means that the 'script' must also run a
    webserver to extract the token, which it can then add to the
    GET/POST/whatever request.

    (2) Subversion has to know about this in some way, and has to run
    the script to use a previously-generated token, or request a new
    one if necessary.

    The first step is not, I think, particularly difficult, and there
    are various existing scripts or apps out there that do some or all
    of the problem. GCM itself looks pretty complex. I'm not really
    sure what the complexity is. The choice to use .NET doesn't help
    (but it has to be multi-platform), but a lot of the complexity is
    presumably in how to use the credential manager to store tokens.
    There's also some complexity in handling different targets
    (GitHub, Bitbucket, Azure, whatever). However, there is a generic
    setup (which I use; this talks to Keycloak). My entire config
    (.gitconfig) to talk to Keycloak looks this:

            helper = cache --timeout 7200
            helper = "oauth"

    [credential "<URL>"]
            oauthScopes       = "openid email"
            oauthAuthURL      =
            oauthTokenURL     =
            oauthClientId     = openid-cli
            oauthRedirectUri  =
            oauthClientSecret = <CLIENT-SECRET>

This was actually discussed over on the TortoiseSVN dev list today in the following thread

I think the steps outlined by Thomas Åkerström is quite similar to what you are also suggesting.

This should probably be discussed further on

Kind regards,

Reply via email to