can we please get LDAP support for logins ??

Patches thoughtfully considered. :)

As one who has implemented LDAP authentication before, I can tell you where a lot of the difficulties lie:

1. Documentation for the canonical LDAP library on FOSS systems, OpenLDAP, is terrible. A huge amount of the online documentation refers to APIs that were deprecated long ago and may only work by enabling backward-compatibility flags on the build. The best book I've found on the topic is now 21 years old. Consequently, writing to this API feels like cargo cult programming.

2. OpenLDAP is being deprecated by Red Hat and SuSE.

3. The intended replacement for OpenLDAP is the 389 Directory Server, but if you go searching for C programming info on it, they point you at Mozilla's LDAP C SDK. They have no internal C library for you to use.

4. Mozilla has abandoned its LDAP C SDK. There are forks floating around, but I have no idea how well they're supported and documented.

5. Encryption. 'Nuff said.

6. LDAP integration only gets you identity authentication. It has poor support for alien authorization schemes such as Fossil's role-based access control system. How do I assign "WriteTrusted Forum" capability to a user via LDAP? How do I map Fossil's "anonymous" group to arbitrary AD configurations? How do I distinguish forum users from subscribers via LDAP?

   Yes, I know, LDAP is just a database, and you can stick anything you want into it, but I doubt you're going to get a lot of buy-in for a solution that requires that administrators do direct LDAP DB manipulation. That leaves either Fossil doing deep AD integration so you use the Fossil GUI to manipulate AD entries, or you split the configuration between the stock AD configuration and Fossil's existing GUI.

   I'm going to assume that by "LDAP" you really mean "Active Directory," in which case what might work better is for Fossil to implement SAML, then enable ADFS on the AD server so we can bounce user authentication through it. That then leaves the Fossil RBAC system in place, naturally, with only identity being delegated to AD.

   As a bonus, the SAML code can then be used with other authentication systems, in principle.

You're going to get right on that SAML + ADFS integration feature, right? :)

As an AD admin, and someone who just went through getting a third party app integrated with AD via LDAP lookups I can say "NO". Don't go that route. (Though encryption is possible with LDAPS, it is definitely non-trivial to implement.)

SAML is definitely the way to go. You really don't want to try and implement the permissions for Fossil in AD, or map AD security groups to Fossil concepts. Much better to do the Authentication via SAML and then the Authorization using existing Fossil features. And as you say, with SAML you can use other identity stores as well (such as letting someone log in here with their Microsoft Account/Facebook Account/Google Account).

Unfortunately my programming pretty much begins and ends with PowerShell these days, and I long ago forgot C (but sort of remember FORTH).

Using the latest Windows 10 Builds (1709, 1803) Windows Mail fully integrates with Exchange Online now. No clue about Exchange On-Prem, but really, just stop hosting your own Exchange. It's not worth it these days.

Or just install Outlook and get full email capability everywhere.

The most important part these days is the Auto-Discovery piece which uses records in DNS to figure out how to auto-configure the email client. If you don't have those DNS records then it is very painful.

configure a web server to authenticate against LDAP/AD

Yes, Apache offers mod_authnz_ldap, but that still leaves your users retyping their AD user name and password into a browser's HTTP basic auth dialog. Not only is that annoying, it means that in order to avoid doing that frequently, the browser will have to store that password in the clear. (Or symmetrically encrypted under a key stored on the same computer and under the same user account, which is a distinction without a difference to a motivated attacker.)

The SAML + ADFS method should be a true single sign-on solution, meaning that the remote AD server will realize that your user is already logged in, and just bounce the user back to Fossil with an "OK, go ahead as user $USER" type of response. No user credentials are ever stored on the local machine with this scheme.

You've sold me on SAML + ADFS Warren.

Yet every time I google about it, I can't help but finding incomplete and confusing information about it. It's probably my own failing, I know.

Similarly to Fossil's C server, I have a custom HTTP/WebSocket server in native C++, thus the usual tutorials assuming Node.JS or .NET or Go or Python etc... are of little use, since using prepackaged solution (if I find anything).

And figuring it out from scratch, at the raw HTTP level, is not trivial at all. Not is how to configure the ADFS side (which I don't control, and my AD admin is not an easy person to deal with, to say the least).

WebApp authentication is like black-arts to me... A bit inscrutable.

So given how knowledgeable you seem to be about the subject, do you know of resources like in depth-tutorials that explain it from A to Z, from scratch? Any pointers would be appreciated. The ones you already provided just don't provide enough hand-holding for me.

I'm asking for my own app here, but seems to me whatever info you'd provide would apply equally well to Fossil itself, for anyone willing to provide the patches you requested when this thread started. Thus I thought this isn't OT.

Thanks, --DD

If you are going to implement the feature, then worry only about SAML, or OAuth, as either will work with ADFS v4 and above. Leave ADFS to ADFS people (I do. It's too specialized for a general AD guy like me). If you implement SAML or OAuth as per the standards for those protocols, it should work fine with ADFS (or any other identity store).

I've been involved in two dev projects where ADFS was needed. In one of them we went through several outside dev teams who were so scared and intimidated by the ADFS side they never produced any code. We finally got a team that just implemented SAML in relatively short order without worrying about ADFS and everything works fine. The other project decided to implement OAuth and it was also nearly painless.

I'm just an AD and server guy. I don't code, but I do love using Fossil to keep track of all my PowerShell scripts and configuration files.

If use of an outside identity store is important, then someone should check and see what types of stores people would want (AD, Google, Microsoft Accounts, Facebook?), see what identity verification protocol is the most common, and implement that. Don't worry about the back end store per se.

LDAP and SAML are complicated enterprisey specs. The incentives that produce such specs are not aligned toward production of simplicity and clarity. You cannot expect to pull up complete information on such specs in a Google search result list.

The anonymous advice above about ignoring ADFS is probably impractical for the person implementing this. To develop the feature, someone's going to have to stand up an AD server, enable ADFS on it, and configure it properly, else the feature's developer will have nothing to bounce packets off of. Unless that developer can fob the job off on someone else, like a friendly local AD admin, the developer of the feature will likely have to be the one to attain with that understanding. In that case, the developer also probably won't be fully insulated from having to understand something about LDAP, even though SAML is supposed to insulate you from it.

I assume you're already working somewhere that has an AD server, but I suspect they won't be happy with the idea of developing brand new authentication code against their existing server, which probably doesn't even have ADFS enabled on it yet. This sort of thing is usually best done with a test machine or VM running the AD + ADFS services. You shouldn't start bouncing packets off the real server until you've got something that functions in test.

Regarding the tutorials you've found in other languages, that's probably because they've already got a SAML implementation and a standard packaging system to distribute it. The closest thing we have to such an easy path in the C world is searching GitHub.

...which eventually lead me to ZXID, which looks like a suitable starting point. Fortunately so, since that's the only body of suitably-licensed C code implementing SAML that I found.

(That is, I believe Apache 2 is compatible with Fossil's license, but IANAL.)

I am that anonymous above... No need to spin up an ADFS server when Microsoft will do it for you... Azure AD SAML. You should be able to spin up a small dev focused Azure AD instance for little to no cost. Also gives the benefit of making sure you can work with Azure AD as well.

Thank you both. These are helpful advice.

SAML isn't too bad. I wrote a SAML IdP in Tcl in a couple hundred lines (it just mapped the user's TLS client certificate to a username, so the identity function was trivial).

I wrote a SAML IdP in Tcl in a couple hundred lines

The efficiency multiplier from Tcl to C is 5-10, depending on the type of code, so I'd expect the equivalent in C to be one or two thousand lines of code.

I don't see that Fossil currently depends on any XML parsing libraries, such as Expat or libxml2. That'll be required, too.

I've used both of those libraries before, and I'd recommend libxml2 over Expat for this task.

Expat is a stream-oriented parser, meaning that you have to write code to react to elements, attributes, CDATA, etc. in the document as the parser encounters them. That makes it great for custom document formats where every little bit is meaningful to your application, but not so great when you just want to extract a few things from someone else's document format.

libxml2 can work in a stream-oriented mode, too, but it also offers a DOM mode, where the library parses the document into an internal data structure, then lets you work with that fully-parsed form. If you only need a few elements, you don't even have to walk the tree, you can just query it with XPath. It's rather verbose to do this in C, but not nearly so bad as writing Expat event handlers.

I'm not sure why you would want to write the identity provider (IdP) portion in C rather than Tcl.

The service side (Service Provider; SP) -- which is where Fossil would be involved -- is much simpler and as verifying a SAML assertion is almost trivial (since it uses xmldsig, which your XML library is could support).