Authelia as a U2F/SSO/TOTP provider

[technotame]

I wanted to suggest Authelia as a way of providing Cloudron with SSO, U2F, TOTP, etc. for all apps, especially those which do not support it natively. It seems like it's already packaged for Docker.

Just something to look into. Having U2F with my Yubikey for all Cloudron services would be pretty sweet.

[iamthefij]

I'm working on packaging Authelia as a Cloudron app, which is slightly different.

Use case is that I have a second server with some services that I would like to authenticate against my Cloudron LDAP.

[technotame]

Having it as a Cloudron app would be great too. Hopefully both is possible. @girish Any idea if this is possible?

[fbartels]

I would think that for authelia the same arguments could be made like for shibboleth

https://forum.cloudron.io/topic/1696/shibboleth-idp/2

[iamthefij]

After making a few upstream patches to Authelia, I've gotten an Authelia Cloudron App running! (yay!)

Unfortunately it won't work due to the Cloudron Nginx config. (Bummer!)

Repo and context for those interested https://git.cloudron.io/iamthefij/authelia-app

Would be cool to have still, but I'm not ready to dig through the Nginx changes given how broad the impact would be.

[technotame]

Thanks for working on it! Maybe @girish can help with the nginx config or at least confirm if changes are possible to accommodate Authelia.

[nebulon]

I moved this to the app wishlist section, since it is more suitable as a Cloudron app at the moment.

[iamthefij]

I'm blocked on getting the app working without a little guidance from @girish on why nginx is overwriting the X-Forwarded-* headers.

[iamthefij]

@nebulon any idea how I can get some clarity here so that I can deliver this app?

[nebulon]

The headers are set in the reverse proxy since many apps expect them to be there to figure our how they are publicly reachable. What exactly is the issue for this app with the headers being set?

[iamthefij]

@nebulon in order to determine what application to authorize, Authelia needs to know what URL was forwarded to it. Since Cloudron overwrites this, Authelia always thinks you’re trying to authorize access to the Authelia domain.

A simple fix would be to only set the headers if the header is not already set.

Do you recall what apps required this header? I can do some more digging into how headers are set with the Authelia example configs and maybe come up with a more flexible patch. Possibly setting up an app add on to pass through headers.

[iamthefij]

@iamthefij @girish do you remember why this header is being written? Any idea what effects of this type of change would be.

[girish]

@iamthefij The headers are a de-facto standard. For example, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For is the IP address of the client. Without this, all the apps would think the connection came from the reverse proxy. And thus rate limiting tools, logging/auditing/analytics etc all break without it. You can grep for those headers here: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

I don't completely understand how Authelia can help in SSO across two Cloudrons. Can you help me understand how that would work? We were also thinking of making the LDAP server on Cloudron "public". Would this help?

I am also not sure why authelia uses these headers for authentication. That seems strange.

[fbartels]

@girish said in Authelia as a U2F/SSO/TOTP provider:

I don't completely understand how Authelia can help in SSO across two Cloudrons. Can you help me understand how that would work? We were also thinking of making the LDAP server on Cloudron "public". Would this help?

This depends a bit on your exact definition of "SSO". While having access to the same user source (the ldap tree) from multiple system does help with working with a unified username/password its not really a single sign on in the sense of logging in just once and being automatically logged into a different application as well. The last case is exactly where protocols such as SAML (old xml based) or oauth 2.0/openid connect come into play. you login once at your "id provider" and when you visit another applications it asks your provider if you're already logged in (simplified, but still). You the maybe need to give explicit consent for this other application to access your data, but you do not need to provide the application with your username/password.

in regards to security openid can also help protecting applications with 2fa from a central point (your openid provider).

[girish]

@fbartels I should have been more clear. I don't understand how Authelia would work as SSO in a two cloudron setup. Does it need any changes in Cloudron? If so what changes are needed?

[fbartels]

@girish I have not yet installed Authelia myself, but from the description I would say that for the Cloudron use case it probably goes too far. The way it seems Authelia brings its own user backend, which in Cloudron is already existant (and with email etc your user backend probably holds more details that Authelia is directly designed for).

But OpenID Connect (oidc) support in general would be very nice. The idea behind this would be that the same login mask you use to log into my.cloudron.io would be shown when for example logging into gitea, codimd, possibly Mattermost (through their gitlab auth) and Rocketchat (has support for oauth 2.0 which is the base for oidc).

For the "multiple cloudron setup" its imho secondary. If you want to go multiserver then you should probably have a copy of the users on your additional servers, afaik your users are not natively in ldap, but your ldap server is implemented in node. the plus side of openid connect could be that you could round robbin between your openid providers.

[iamthefij]

@girish The headers are intended to pass along the information about the original forwarded request. In the case where trying to use forward authentication against a host, let's say cloud.example.com, the X-Forwarded-Host for the initial request to the reverse proxy would be cloud.example.com. When performing forward auth, a new request is made to the auth server at auth.example.com, without modifying the X-Forwarded-Host header, as this is all still considered part of a request to could.example.com.

My original suggestion may actually not be secure. So let's ignore that for now.

The other way to solve this would be to host on a custom port and access via IP address to avoid the reverse proxy, but I'm not sure I like that as it would require more work to use TLS. I can try to dig into the examples of Authelia with Nginx some more and see how they configured this part. I have thoroughly forgotten where I left off.

[girish]

@iamthefij For your original use case of having two cloudrons have same user directory, would it help if a) Cloudron LDAP is exposed publicly and b) Cloudron has a way to integrate with an arbitrary LDAP server.

Of course, we have neither of the above features. Just asking Atleast a) is quite easy to do, we just have to make the existing LDAP server public and put in security blocks and rate limits.

[iamthefij]

@girish yea. Exposing a secure proxy to the LDAP server was my first plan. After I found Authelia, I figured this would be a somewhat simpler option...

Unfortunately, it doesn't actually appear to be so simple.

I was thinking of a using a containers to bridge a connection to the LDAP server via a VPN, but I haven't gotten around to figuring it all out yet.

[nebulon]

Just to keep you updated on this issue, we have started work to add the ability to use an external LDAP server (and thus later also ActiveDirectory) for user integration. We will put out an initial version of it soonish to test and gather feedback what features we have to provide in that area to make it useful. There are a couple of open questions which we cannot easily answer without a real use-case. For example how to map attributes and what do when username/email collisions with Cloudron local accounts happen. Any feedback is highly appreciated.