Samba VS OpenID

You could try to use samba via cgo.

> First, the article doesn't say that "Linux is not ready for the desktop" - or concern itself with this as an abstract question.

Well, it does, but in a sarcastic manner:

"Yeah, let's consider Linux an OS ready for the desktop :-)."

> Also, I find the "GNU/Linux is already ready for the desktop; I and others use it" argument tired. I've used GNU/Linux for the desktop in 1998, but it sure as hell wasn't ready then.

Conversely, that it doesn't work for certain people does not mean that "it is not ready", which the post does state (sarcastically) as I pointed out above.

> Many use cases aside...

I'm not sure how the browsing, docs and email is miserable, maybe you can expand on that. The video editing is indeed a bit limited from my experience too. However, I don't think "limited proprietary options" is a problem. The community largely and specifically avoids proprietary software. Proprietary incursions into the community are generally seen as a negative thing. And for the lack of codecs, software patents for the most part are to blame.

And then it just comes to my original statement; many things stated in the article are non-issues to most Linux users or just falsehoods:

- Neither Mozilla Firefox nor Google Chrome use video decoding and output acceleration in Linux.

Firefox does.

- NVIDIA Optimus technology is a pain

NVIDIA is a pain.

- You don't play games, do you?

I do.

- Linux still has very few native AAA games.

So "it's not ready" because it doesn't have AAA games? What a pitty.

- To be fair you can now run thousands of Windows games through DirectX to Vulkan/OpenGL translation (Wine, Proton, Steam for Linux) but this incurs translation costs and decreases performance sometimes significantly.

No, not 'significantly' for dxvk.

- Also, anti-cheat protection usually doesn't work in Linux.

For good reason. Blame the dev, and don't make it work on Linux.

- Microsoft Office is not available for Linux

Thankfull.

- LibreOffice often has major troubles properly opening, rendering or saving documents created in Microsoft Office.

And whose fault is this? Use ODT.

- Several crucial Windows applications are not available under Linux.

Thankfully. Also, 'crucial' is subjective.

- In 2022 there's still no alternative to Windows Network File Sharing.

It's available since 1992: https://www.samba.org/

- Linux doesn't have a reliably working hassle-free fast native (directly mountable via the kernel; FUSE doesn't cut it) MTP implementation.

I can transfer files to my phone just fine.

- Too many things in Linux require manual configuration using text files.

No.

etc.

brew info samba samba: stable 4.16.0 (bottled) SMB/CIFS file, print, and login server for UNIX https://www.samba.org/ Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/samba.rb License: GPL-3.0-or-later ==> Dependencies Build: [email protected] ✔ Required: gnutls ✘, krb5 ✔ ==> Caveats To avoid conflicting with macOS system binaries, some files were installed with non-standard name: - smbd: /usr/local/sbin/samba-dot-org-smbd - profiles: /usr/local/bin/samba-dot-org-profiles ==> Analytics install: 1,477 (30 days), 3,287 (90 days), 6,917 (365 days) install-on-request: 1,459 (30 days), 3,246 (90 days), 6,863 (365 days) build-error: 5 (30 days)

The best thing about net send is, it's entirely unauthenticated -- or at least it was, back in the day. It says "User X on Machine Y" sent this message, and Windows will indeed make sure to tell the other machine who sent the message. But if someone were to reverse-engineer the Windows filesharing and related protocols and turn these into a nice suite of open source tools, nothing would force those tools to tell the truth about which user or machine was net-sending.

You need to deploy AD. Even Samba can do it.

Samba Official

I wanted a solution that was relatively easy to access on a local network and elsewhere. Preferably the same solution used the same way in both cases. This requirement ruled out Samba shares, as it's not designed for sharing across the internet. I looked at NFS, but encountered speed and reliability issues, and recent macOS support is poor with documented workaround to enable version 4 seemingly not working anymore.

I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_openidc

In other words, I can protect arbitrary applications through my reverse proxy and require either certain claims/roles, or simplify auth to the point where my downstream app/API will just receive a bunch of headers like OIDC_CLAIM_sub, OIDC_CLAIM_name, OIDC_CLAIM_email through the internal network, not making me bother with configuring OIDC libraries for all of my APIs and configure them in each stack that I might use, but rather contain all of that complexity in the web server.

Basically:

  user <==> Apache (with mod_auth_openidc) <==> API (with OIDC_ headers, if logged in)

> Don't outsource either your authentication or authorization. Run it in-house.

This is hard to do, though. I hope people here will drop a lot of combinations that work for them!

Personally, for a small/medium scale project, I went with:

Keycloak: https://www.keycloak.org/

It supports various backing RDBMSes (like PostgreSQL, MariaDB/MySQL and others), allows both users that you persist in your own DB, as well as various external sources, like social login across various platforms, is an absolute pain to configure and sometimes acts in stupid ways behind a reverse proxy, but has most of the features that you might ever want, which sadly comes coupled with some complexity and an enterprise feeling.

I quite like that it offers the login/registration views that you need with redirects, as well as user management, storing roles/permissions and other custom attributes. It's on par with what you'd expect and should serve you nicely.

mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc

This one's a certified OpenID Connect Relying Party implementation for... Apache2/httpd.

Some might worry about the performance and there are other options out there (like a module for OpenResty, which is built on top of Nginx), but when coupled with mod_md Apache makes for a great reverse proxy/ingress for my personal needs.

The benefit here is that I don't need 10 different implementations for each service/back end language that's used, I can outsource the heavy lifting to mod_auth_openidc (protected paths, needed roles/permissions, redirect URLs, token renewal and other things) and just read a few trusted headers behind the reverse proxy if further checks are needed, which is easy in all technologies.

That said, the configuration there is also hard and annoying to do, as is working with OpenID Connect in general, even though you can kind of understand why that complexity is inherent. Here's a link with some certified implementations, by the way: https://openid.net/developers/certified-openid-connect-imple...

otherwise connections would randomly drop. I was looking for other ways to make development a bit easier and also settled on mod_auth_openidc, which is an Apache module that lets it act like a Relying Party and handle lots of the heavy lifting (protecting endpoints, refreshing tokens etc.) for me, and lets me work with just a few headers that are passed to the protected resources: https://github.com/OpenIDC/mod_auth_openidc

It works, but I'm still not happy - I realize that there are many types of attacks that have historically been a problem and that certain OpenID Connect flows try to protect against, in addition to the fact that if I wrote my own security code it'd almost certainly be worse and have vulnerabilities (in the words of Eoin Woods: "Never invent security technology"), and it's a good thing to follow standards... but the whole thing is such a pain. Both OpenID Connect, Keycloak and configuring mod_auth_openidc.

Right now I'm moving permissions/roles from Keycloak back into the app DB, with references to the Keycloak user IDs, because I don't want to have to work with the Keycloak REST API every time I want to change what a user can or cannot do in the system, in addition to permissions which might only apply conditionally (one user might be related to multiple organizations, having different permissions in the context of each).

Regardless, it's nice that there are more pieces of software out there to choose from!

Personally I went with Keycloak, because it's fairly well documented and also has Docker images available: https://www.keycloak.org/getting-started/getting-started-doc... although the fact that they want you to create an "optimized" image yourself and have a long build/setup process on startup instead is slightly annoying: https://www.keycloak.org/server/containers

Regardless, with something like mod_auth_openidc or another Relying Party implementation, all of the sudden authn/authz becomes easier to manage (you can literally get user information including roles in headers that are passed from your gateway/relying party to apps behind the reverse proxy), regardless of what you have actually running in your APIs: https://github.com/OpenIDC/mod_auth_openidc (there are other options, of course, but I went with that because I already use mod_md).

It's actually cool that there are plentiful options in the space, since OIDC is pretty complex in of itself and attempts at creating something pleasant to actually use are always welcome, I've also heard good things about Authentik: https://goauthentik.io/

> The user experience with basic auth is not so good.

Apache actually also has an OpenID Connect module, which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc

Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/

I'd say that Keycloak is a pretty good solution in general, because it does some of the heavy lifting for you, maybe its shorter release cycle not being the best thing ever, though. I think IdentityServer also tried to fill this niche, but they went full on commercial recently, without OSS offerings.

E.g. for Apache httpd there's mod_auth_openidc available.

I really like https://tools.ietf.org/html/draft-ietf-oauth-security-topics with it's evergreen approach and looking forward to oauth2.1 to sum up the current best practices.

Depending on your use case I have good experience with https://github.com/zmartzone/mod_auth_openidc and https://github.com/panva/node-oidc-provider.

https://github.com/OpenIDC/pyoidc also might be a good choice as security researchers in that area did take a look in it...

I leave that the the module, I believe it uses client cookies by default, but I use a persistent server cache on disk (the session tokens are stored encrypted)

https://github.com/zmartzone/mod_auth_openidc/wiki/Session-m...