proxyAuth addon

girish

allow the request if there are BasicAuth credentials

Done (I saw what you did for transmission and did similar) ! https://git.cloudron.io/cloudron/box/-/commit/641704a74107fab7c54220428b7d4df3676f51d1

ei8fdb

@nebulon said in What's coming in 6.0 (take 2):

Alternately, we could certainly add a login screen served up with some kind of session. The question then, as already mentioned, is how to logout. We could provide the app with a logout link, still that needs patching the app to some extent.

As I understand it, these are personal media apps, right? Is there therefore a need to logout?

What would happen if a user was able to login, but not log-out? They could close the browser window?

girish

@ei8fdb I moved your comment to this topic. I think the auth wall applies to all apps which don't have a notion of user management. For example, apps like prometheus etc as well.

ei8fdb

@girish Gotcha.

OK. I've used 2 apps that (I think) don't have user management natively - youtube-del and surfer files app. Is that right?

girish

@ei8fdb Indeed, other apps are transmissions, cloud torrent. They can all use this addon.

fbartels

@ei8fdb said in proxyAuth addon:

surfer

Surfer has auth for it's backend

saikarthik

This post is deleted!

Lonkle

Heck, I'd probably switch to this option if my app didn't need to use LDAP to also grab an access token to get permission to restart and repair apps on-demand (if it doesn't already have an app access token, that is).

atridad

@girish I have a request/question. How tedious would it be to incorporate a way to allow customization of the plugin to specify which routes should be protected in the app? For example, if someone wanted to make a cloudron specific app for personal use, would it be possible to allow this plugin to do the heavy lifting in terms of auth and protect routes like /admin, for instance.

What I invision is basically the following use cases:

an empty list of routes -> all routes are protected
a list of routes is provided -> only the specified routes are protected

I think this could be a game changer for using Cloudron for business apps or people building out their dev stack entirely on Cloudron without compromising the simplicity of the feature.

Example:

proxyAuth: {
    routes: [
        'admin',
        'profile'
    ],
}

EDIT: Also, this just came to my mind: can apps using this plugin access the LDAP info like name, email, etc? I realize I am probably your worst nightmare with these requests but just thought I'd try.

girish

@atrilahiji said in proxyAuth addon:

How tedious would it be to incorporate a way to allow customization of the plugin to specify which routes should be protected in the app

Currently, up to 1 route can be protected - https://docs.cloudron.io/custom-apps/addons/#proxyauth . So, it's basically what you are asking for except that only one route can be protected.

Also, this just came to my mind: can apps using this plugin access the LDAP info like name, email, etc?

I guess we have to make up some HTTP headers to pass on this info like X-REMOTE-USER or something.

atridad

@girish Wow I totally didn't realize there were docs for it. Sorry for bugging you!

girish

@atrilahiji I just recently pushed it

saikarthik

@girish is there a way to get the username/email from within the app?

nebulon

@saikarthik currently not, I guess the only option would be to add the username/email as a header in the requests?

jimcavoli

@nebulon That would seem a sensible approach. Similar to other gateway authentication solutions I've seen. Definitely would need to restrict trust of those headers either in app or sever configuration though to prevent escalation/impersonation/ato attacks

nebulon

@jimcavoli is there any risk or impersonation angle, if the reverse proxy always explicitly overwrites that header?

jimcavoli

@nebulon Yes, an always-overwrite would mitigate as well, as long as the edges get tested well, might be the easier solution

saikarthik

@nebulon @girish is this something that can be added to cloudron? passing logged in username/email ID to apps through the header? Any comments/issues?

girish

@saikarthik yup, can surely be added. probably next release.

jimcavoli

Related: while re-working the n8n packaging, I happened upon what would probably be reasonably common, where there are selected sub-paths of / which should not be authenticated - example being we want / to require auth, but not /webhook/* paths. It's at least non-obvious if not unsupported by the current docs on how to do this with proxyAuth

girish

@jimcavoli Indeed, that's not something I designed for. How complicated can these rules get ? Atleast, https://docs.n8n.io/reference/security.html does not seems to have any more information. Or should I just add a publicPath property (singular) and that's enough ? I like to under-design these things and extend them as use cases come.

mehdi

@girish I think the best would be to have the path in proxyAuth be an array, where given paths can be either positive or negative. It's the way things like .gitignore work.

For example, in this case, it would be:

{
  "proxyAuth": [
    "/",
    "!/webbooks/"
  ]
}

thetomester13

@mehdi I like this solution and its flexibility. It could also be backwards compatible with the currently version - if no paths are specified, everything is auth'ed.

jimcavoli

Agree on the default behavior - I imagine it's unlikely that anything more specific than path-level exceptions are unlikely. Perhaps as an extension to the solution that @mehdi suggests, we could extend the existing format of:

{
  "proxyAuth": {
    "path": "/admin" 
  }
}

To take exceptions:

{
  "proxyAuth": {
    "path": "/admin" ,
    "exclude": [
      "/webhook",
      "/
    ]
  }
}

Or with probably over-the-top features, make everything a map of path and exception(s):

{
  "proxyAuth": {
    "paths": {
      "/" : [
        "/webhook",
        "/public"
      ],
      "/admin": []
    }
  }
}

Honestly, I appreciate the minimal-first approach, and I think the middle option of adding a (understood to be auto-wildcarded) array of exclusions is the easier next step. I can't imagine anything that would need the super-complex variant would be something that would or should rely on such a mechanism to secure it.

nj

@girish I don't see the 2FA code prompt on the login page of Simple Torrent. Am I missing something?

Some benefits of having this on the platform side (as opposed in the app are):

2FA login

mehdi

@nj I don't think this is implemented either:

Session management in the user's profile page. i.e can logout from apps etc

I think @girish just meant that it would be possible to implement this in the future, not that it would be in the first version of proxyAuth.

girish

@nj I have logged it here - https://git.cloudron.io/cloudron/box/-/issues/748 . As @mehdi said, it wasn't implemented as part of the first iteration of proxyAuth.

girish

@jimcavoli Shall I go with path: "!/webhooks" for now? Will this be enough for n8n ?

jimcavoli

@girish Yeah, that would be enough for n8n I think, though if we're going to go that route, I think making paths an array of either path(s) and/or ! paths makes the most sense in general (at least somehow providing for the option of multiple excluded paths)

girish

@jimcavoli won't having it plural cause some confusing semantics if you mix ! and no ! paths ? Let me think

mehdi

@girish It works for .gitignore files

girish

@mehdi great point. I can copy what they do.

murgero

@girish Currently ~~I have an app that this does not work on - is there something special I need to do in the app beyond adding the addon to the addon list?~~

Edit: I am blind I swear - just formatted the JSON incorrectly for the manifest.

saikarthik

@girish Hi Girish, what is the status of this? selectively exposing certain paths to public?

mehdi

@saikarthik Girish answered here : https://forum.cloudron.io/post/23886

Yes, proxyAuth exclusion is implemented. I only implemented a simple approach with a ! pattern for now (not an array).

hendrikvl

I have a question regarding the proxyAuth addon: If I understand it correctly, it has to added to the manifest file and therefore is only suitable for custom apps. How about an option to enable it for apps that have built-in authentication as well?

In my case, I would like to hide the public site of an Shaarli-instance behind the proxyAuth login. Such that authenticated users can browse the public page and I can additionally login using the builtin auth as admin.
I know, that this usecase is somewhat specific and customary, but it is just meant as an example of possible use cases for an proxyAuth-option with the standard apps.

mehdi

@hendrikvl I don't use Shaarli, so I don't know about it very well, but in my opinion, the clean way to do this would be to request the upstream project (Shaarli) to allow an option to protect stuff behind its own auth wall, and have 2 types of users, normal & admin. It seems "hacky" to me to solve this usecase with Cloudron's proxyAuth

girish

@hendrikvl Currently, proxyAuth is designed for cases where the app has no user management at all. I think if an app already has user support like shaarli, it's best to ask the upstream project to password protect the public page as @mehdi suggests. BTW, if you post a request upstream, please do post the link here.

murgero

@girish This plugin works amazing on my alpha build of code-server. Works like a treat.

hendrikvl

@girish @mehdi Thanks for your replies. Since Shaarli is designed as a single-user application, I don't see much chances of getting LDAP integration implemented for the public page.
But you're of course right, that my proposal for the Shaarli public page is a bit "hacky". It was rather meant as an example of what a dynamic proxyAuth-option could be used for. My thought was, that others might have a need for such an option in similar situations as well.

infogulch

I think it would be nice if more apps supported the option to switch to proxyAuth+X-REMOTE-USER-based authentication for multi-user apps. I prefer proxy-based auth for a couple reasons:

I don't trust the login page and password handling to apps. Even if they auth via ldap -- they're still touching the password. Proxy auth eliminates this problem altogether, since they only receive the attestation of the user's identity (the header), no secrets, no cookies. I trust the proxy's auth login page way more.
Ideally the app is never even accessible to the outside world until you're logged in. Apps often have vulnerabilities that can expose data even if you're not logged in. By putting the app behind an authenticating proxy, one can shield it from general internet access, narrowing the scope of attackers from "everyone that can access my ip" to "users on my cloudron" -- a large improvement.
It's by far the easiest auth system to implement first if you write something custom.

Of course, all apps may not support this yet, and sometimes you do want a public-facing service, and some apps could never work like this (bitwarden), etc, hence "optional".

mehdi

@infogulch said in proxyAuth addon:

It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

Cloudron used to have something very similar (in usage, if not technologically), using OAuth. They decided to drop it, because almost no apps supported it.

What you are describing would be indeed quite interesting, but more or less custom to cloudron : i think this would be even more difficult to convince upstream devs to implement, because it's so custom.

Do you know of any apps that currently support a similar thing ?

infogulch

I did some searching ("reverse proxy authentication", "header proxy auth"). I offer these examples for your consideration:

open source Kanban project management software Kanboard
- REMOTE_USER
Jenkins
- X-Forwarded-User
Docker suggesting using it to secure access to a registry (Not sure how applicable this one is.)
Microsoft recently published some docs on how to configure Azure AD to do proxy auth, as well as another article
Authelia (?)
Some Oracle enterprise apps
Some stack overflow questions in this area:
- https://stackoverflow.com/questions/33368653/how-do-i-set-remote-user-in-a-http-header
- https://serverfault.com/questions/180726/remote-user-through-apache-reverse-proxy

Perhaps this solution is more common in enterprise apps. Probably for the security reasons I mentioned before.

There's also RFC 7615 / Proxy-Authenticate on MDN which seems related.

Thoughts?

Edit also:

infogulch

@mehdi said in proxyAuth addon:

It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

I'm just saying that if you can build your app assuming it's behind an authenticating reverse-proxy, it frees you from a LOT of work designing a system to authenticate the user with credentials or whatever. It's just username = request.Headers["X-Forwarded-User"], done. No validation, no encryption, no hmac, no password hashing function, no password storage, no password resets, etc etc etc

mehdi

@infogulch That's totally true, but it assumes that apps are built with Cloudron specifically (or something similar) in mind. It's not the case for most Cloudron apps at the moment

infogulch

@mehdi I think we can add Firefly III to the list of apps that use this authentication strategy.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

proxyAuth addon