Re: Repo access with HTTPS and an access token (or: GCM for svn?)

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 
<https://github.com/indigo-dc/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 (kit.edu <https://www.kit.edu/>) and, I 
think, would be interested in this. I have a bit more time now so I'll 
have another look at this.

-Evan

On 29/03/2024 15:46, Daniel Sahlberg wrote:
> Den fre 29 mars 2024 kl 16:27 skrev EML <[email protected] 
> <mailto:sa212%[email protected]>>:
>
>     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
>     <https://github.com/git-ecosystem/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:
>
>     [credential]
>             helper = cache --timeout 7200
>             helper = "oauth"
>
>     [credential "<URL>"]
>             oauthScopes       = "openid email"
>             oauthAuthURL      =
>     /keycloak/realms/<REALM>/protocol/openid-connect/auth
>             oauthTokenURL     =
>     /keycloak/realms/<REALM>/protocol/openid-connect/token
>             oauthClientId     = openid-cli
>             oauthRedirectUri  = http://127.0.0.1
>             oauthClientSecret = <CLIENT-SECRET>
>
>
> This was actually discussed over on the TortoiseSVN dev list today in 
> the following thread 
> https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8
>
> 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 [email protected].
>
> Kind regards,
> Daniel
>
>