Is the OIDC Addon a kind of... "instant App Proxy" for packaging apps?

[jadudm]

Description

How does the OIDC addon work?

(Is there a "packaging" tag? It seems no? So, I'm filing this question under "Support." Should be an easy one.)

Steps to reproduce

https://docs.cloudron.io/packaging/addons/#oidc

I could experiment, but I'd rather ask.

Does this add-on let me do the following:

1. Package an app that is (at some level) insecure
2. "Wrap" an OIDC/Cloudron login around it
3. Choose where to go after authentication

In other words, is this "App Proxy" for arbitrary apps? Can I make it point at my local Cloudron instance, and get "magic" OAuth (with a redirect... to myself?) for an app that I'd rather not modify/extend to have OIDC?

The reason I ask is because I'd like to package something, but it 1) allows user creation in an unrestricted manner, and 2) I don't want to deal with it. I'd rather put it behind Cloudron's OIDC, and (as a first step), and once authenticated, bounce them through to the app. This would still require people to create a second account, but I can live with that. At least I'd know that I can restrict access using Cloudron's groups feature, and therefore get a reasonably secure app with minimal effort.

Logs

I haven't tried anything yet, so there are no logs.

However, another sentence or two in the Addons section of the docs for the OIDC add-on might be useful, so we know how it works/how to use it.

Troubleshooting Already Performed

None. I looked at the docs, and it is not obvious from the docs what this add-on does.

System Details

I don't know that it matters, at the moment.

Generate Diagnostics Data

Tricorder malfunction.

Cloudron Version

8.x.2, I think. I forget the 'x'. 3?

Ubuntu Version

24.02.

Cloudron installation method

A long time ago, on an SSD far, far away...

Output of cloudron-support --troubleshoot

N/A

[james]

Hello @jadudm

@jadudm said in Is the OIDC Add-on a kind of... "instant App Proxy" for packaging apps?:

Package an app that is (at some level) insecure

No.
The OIDC add-on is for apps that have OpenID capabilities and the add-on configures Cloudron itself for the app and gives the app the documented variables to configure the app.
Example for that would be Nextcloud from the start.sh#L168-L178:

# OIDC
if [[ -n "${CLOUDRON_OIDC_ISSUER:-}" ]]; then
    echo "==> Ensure OIDC settings"

    $occ app:install user_oidc || true

    # --group-provisioning=0_or_1 is intentionally not set, this is up to the user
    $occ user_oidc:provider "Cloudron" --clientid="${CLOUDRON_OIDC_CLIENT_ID}" --clientsecret="${CLOUDRON_OIDC_CLIENT_SECRET}" \
        --discoveryuri="${CLOUDRON_OIDC_DISCOVERY_URL}" --scope="openid email profile groups" --mapping-groups="groups" \
        --unique-uid=0 --mapping-uid=sub
fi

@jadudm said in Is the OIDC Add-on a kind of... "instant App Proxy" for packaging apps?:

"Wrap" an OIDC/Cloudron login around it

No.
This would be the proxyauth add-on for apps that have no user management or for apps that lack a good user management (like your case).

@jadudm said in Is the OIDC Add-on a kind of... "instant App Proxy" for packaging apps?:

In other words, is this "App Proxy" for arbitrary apps? Can I make it point at my local Cloudron instance, and get "magic" OAuth (with a redirect... to myself?) for an app that I'd rather not modify/extend to have OIDC?

Yes.
Let's take the lamp-app which by default has no OIDC capability and is public by default.

Full app behind proxyauth

Add the proxyauth add-on, the lamp app to have the Cloudron OIDC log in form before access to the app is given.
Here is the git diff of the CloudronManifest.json for that:

diff --git a/CloudronManifest.json b/CloudronManifest.json
index 6555084..691bdd2 100644
--- a/CloudronManifest.json
+++ b/CloudronManifest.json
@@ -13,6 +13,7 @@
   "contactEmail": "apps@cloudron.io",
   "icon": "logo.png",
   "addons": {
+    "proxyAuth": {},
     "mysql": {},
     "localstorage": {
       "ftp": {

I have deployed this custom app to https://proxyauth-lamp.cloudron.dev.
When accessing the URL, you can see the login for Cloudron.
By contrast, here is the default lamp app https://default-lamp.cloudron.dev/ which is just publicly accessible with no authentication.

Partial app behind proxyauth

From the proxyauth docs I can limit just the access to e.g. /admin:
git diff for that:

diff --git a/CloudronManifest.json b/CloudronManifest.json
index 6555084..5f3c90e 100644
--- a/CloudronManifest.json
+++ b/CloudronManifest.json
@@ -13,6 +13,7 @@
   "contactEmail": "apps@cloudron.io",
   "icon": "logo.png",
   "addons": {
+    "proxyAuth": { "path": "/admin" },
     "mysql": {},
     "localstorage": {
       "ftp": {

I have deployed this custom app to https://proxyauth-admin.cloudron.dev/.
Which is publicly accessible, but when you try to access https://proxyauth-admin.cloudron.dev/admin you will get the proxyauth screen and need to authenticate against the Cloudron.

Default way without Cloudron add-on

You could always use .htaccess and .htpasswd to limit access to certain paths of an app.

@jadudm said in Is the OIDC Addon a kind of... "instant App Proxy" for packaging apps?:

The reason I ask is because I'd like to package something, but it 1) allows user creation in an unrestricted manner, and 2) I don't want to deal with it. I'd rather put it behind Cloudron's OIDC, and (as a first step), and once authenticated, bounce them through to the app. This would still require people to create a second account, but I can live with that. At least I'd know that I can restrict access using Cloudron's groups feature, and therefore get a reasonably secure app with minimal effort.

So you actually only want to restrict the access to the user creation of your custom software with an authentication mechanism, did I get this right?
Then, the proxyauth add-on limiting access to the user creation would be the correct thing to try, like I demonstrated above for the lamp app.

But be we aware, all users in Cloudron, who are configured to have access to the app, either by all, user or group level, will be able to log in with proxyauth and then access the user creation of your custom software.
Which you could limit like this for the https://proxyauth-admin.cloudron.dev/ app:

This way, only the user james can see the app in the Cloudron Dashboard and is the only one able to authenticate in the /admin path.
So if I try to access /admin and authenticate with the test user I get:

@jadudm said in Is the OIDC Addon a kind of... "instant App Proxy" for packaging apps?:

However, another sentence or two in the Addons section of the docs for the OIDC add-on might be useful, so we know how it works/how to use it.

Thanks for the feedback, still I have to ask what exactly is unclear?
The documentation declares This addon provides OpenID connect based authentication.
Which is clear to me, but I am standing inside the forest and can say, yes this tree is a red-pine tree, and it is 22 years old.
So your outside perspective of how to better communicate this information is very valuable.

Maybe we should phrase it like that?

This addon provides OpenID connect based authentication.
The app itself needs to have OpenID capabilities to use this configurations

---

I hope this made the add-on OIDC and proxyauth more understandable and helps you packaging your custom app.

[jadudm]

Absolutely. That's an excellent and thorough answer, @james . Many, many thanks.

Possible text:

This add-on is intended for applications that already support OpenID Connect-based (OIDC) authentication. Apply this add-on to use Cloudron as an OpenID provider with an application that supports OIDC-based authentication.

Possible improvement for proxyauth:

The proxyauth add-on allows you to put an authentication wall in front of an application. This is useful in situations where the application has no authentication mechanisms of its own, or where there are features that you cannot easily turn off (for the general public), and you want to restrict access using Cloudron's built-in user and group management tools.

I think the idea being that, in both cases, a bit more "why" might help.

Either way, thank you. All of my questions are answered (including "oh, hey, there was an app packaging topic!").