Authelia as a U2F/SSO/TOTP provider
-
@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 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.
-
@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 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.
-
@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, theX-Forwarded-Hostfor the initial request to the reverse proxy would becloud.example.com. When performing forward auth, a new request is made to the auth server atauth.example.com, without modifying theX-Forwarded-Hostheader, as this is all still considered part of a request tocould.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.
-
@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. -
@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.
-
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.
-
Do you know this alternatives? (Don't know if those help:)
https://www.keycloak.org "SSO Alternative"
https://www.privacyidea.org/ "U2fEnabler"
-
For interest:
-
G girish marked this topic as a regular topic on
