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 <sa212+apa...@cyconix.com
<mailto:sa212%2bapa...@cyconix.com>>:
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 d...@subversion.apache.org.
Kind regards,
Daniel
