Hello,

I'm new to fossil and trying to evaluate it for use by my team at work. I see that fossil includes support for multiple users, but from my reading it seems that each repository handles user setup and authentication separately.

Is there any way to centralize at least the authentication portion so that folks can use their standard LDAP or AD username and password to log into fossil? If there's a way to pass through to the standard Linux PAM system (perhaps after setting up a fossil pam service configuration), that would work also.

Thanks, --Joe

Perhaps the best way to achieve that would be to set up Fossil via SSH so you're reusing the existing PAM configuration on the server. That link takes you down the paths of getting the RBAC working, if you need it to work over SSH.

Yes, I could likely make that work technically, but operationally now folks have to learn two things: SSH & Fossil, so it's definitely a fallback.

If you also had to get the web UI working remotely via LDAP auth, I don't believe anything's changed since the big thread we had on it years ago.

Summarizing that thread, it seems like the way to go is to teach fossil to be a SAML SP; but I'm guessing not much has happened in the intervening two years.

operationally now folks have to learn two things: SSH & Fossil,

Who are these Linux users who don't know SSH already?

Anyway, I'm not speaking of anything super-difficult. From the user's perspective, it's:

  $ fossil clone ssh://server/path/to/repo.fossil

Done.

The hard part is setting up the remote Linux box to delegate identity to AD, which your average "enterprise" Linux will have tools for.

it seems like the way to go is to teach fossil to be a SAML SP

That, and then to add a mode to the Fossil login screen to make it contact your AD-FS server, then configure said server to return the delegation back to Fossil once it's verified the identity.

Oh, and to do all of this securely. Insecure IdM is easy: just say "yes" to all questions asked. :)

Apache (and probably other web servers) have modules which enable SAML SP support, which can then be passed into Fossil (using the environment variables noted previously).

The module is called mod_auth_mellon.

Alternatively, I've written an incomplete SAML SP as part of my SAML IdP in Tcl (which ironically isn't production ready, but is good for my resume so is only on GitHub.com and not in a public fossil repo: here).

Can you configure your web server to set either the REMOTE_USER or the HTTP_AUTHENTICATION variables for CGI? If so, Fossil can be configured to use whatever username is in those variables as its login.

Thanks for the quick replies! Some more details:

I'm currently running Debian with Lighttpd as the web server (though that can certainly be changed). I had planned to have fossil running in SCGI mode listening on localhost:9000 (via systemd) and then have lighttpd use mod_scgi to talk to it.

Can you configure your web server to set either the REMOTE_USER or the HTTP_AUTHENTICATION variables for CGI?

Yes, I'll need to research that on the lighttpd side. However, does the SCGI protocol allow passing a variable like that or must I use CGI?

Fossil is able to receive those variables over SCGI. Whether or not lighttpd knows how to send them is another question, which I don't know the answer to.

The SCGI protocol supports it. But does Lighttpd?

It does look possible.

The main problem with the HTTP auth method is that it isn't SSO: the users will be presented with a second login by their browser, where they'll have to re-enter their AD credentials. That has to be done securely to avoid leaking AD creds on the network via the two channels involved: client to HTTP/Fossil server, then HTTP server to AD, and back.

I can see from the docs that lighttpd's mod_authn_ldap is able to handle the second path securely if properly configured, but the other half can be tricky: getting HTTPS working behind a firewall where things like Let's Encrypt can't work. Even though AD can operate as a CA, those running the AD server often don't know how to make it mint certs, and even if they do, the organization's browsers aren't automatically set up to trust those it does mint, at which point you're in self-signed cert hell.

With the SSH method, you can set up keys for access to the Fossil server without providing login creds explicitly: the fact that you can access the private key needed to do the SSH identity exchange proves you are who you say you are. The tricky bit is, can pam_ldap or whatever then use that to prove to the AD server that the client machine's user is who they claim?

With federated identity, it's definitely possible to make it SSO: client machine logs into AD, after which point ADFS gets all three machines to jump through sufficient hoops that everyone's convinced the identities are equivalent. The only problem here is that Fossil doesn't know how to participate in that, doubtless from lacking a user who needs that to work and is motivated to make it work.