User Tools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
selfhost:sso [2024/08/29 09:23] – willyselfhost:sso [2025/03/13 09:29] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Authentication ======+====== G) SSO Authentication ======
  
  
Line 32: Line 32:
  
 A more advanced SSO approach is to use a dedicated gateway like [[https://www.authelia.com|Authelia]]. There are many similar services, but i focused on Authelia because it's fully Open Source in the best concept and it's very well documented.  A more advanced SSO approach is to use a dedicated gateway like [[https://www.authelia.com|Authelia]]. There are many similar services, but i focused on Authelia because it's fully Open Source in the best concept and it's very well documented. 
 +
 +As a side note, a few words on server login capability. Should the user be allowed also access to the server via SSH / console? An answer to this question is not so simple because of the use of services like NFS or Samba, and wether some users might need to login phisically on the server. I leave these considerations to your use case.
  
 So, the NGINX PAM Auth approach: So, the NGINX PAM Auth approach:
-  * Requires the users to be able to also login via SSH / local console on the server+  * Requires the users to be able to also login via SSH / local console on the server (this can be avoided using NGINX basic auth instead)
   * Shows a somewhat ugly (and non-customizable) login popup on the browser   * Shows a somewhat ugly (and non-customizable) login popup on the browser
-  * A bit less overall customizable+  * Much less overall customizable
   * Must login separately for each subdomain   * Must login separately for each subdomain
   * Less flexible, more difficult to integrate with services (no OIDC or OAuth support)   * Less flexible, more difficult to integrate with services (no OIDC or OAuth support)
-  * Easier to integrate with some services, impossible with others +  * Easier to integrate with some services, impossible with others.
-  * Works perfectly with WebDAV / CardDAV / CalDAV and such protocols+
  
 Instead, the Authelia approach: Instead, the Authelia approach:
-  * Much more customizable +  * Much more customizable  
-  * Does not require the user to be able to login on the server+  * Does not let the user to login on the server (unless you link PAM to Authelia)
   * Shows a nicer and customizable login page in the browser   * Shows a nicer and customizable login page in the browser
-  * Once logged on one, it will work for __any__ configured subdomains+  * Once logged on one, it will work for __all__ configured subdomains
   * More flexible, can support OAuth and such   * More flexible, can support OAuth and such
-  * Easier to integrate with some services, impossible with others +  * Easier to integrate with some services (there will still be services that cannot use it) 
-  * Does not work with WebDAV / CardDAV / CalDAV and such protocols+  * Can simoultaneously use also __basic authentication__, which is required by some protocols like WebDAV.
  
-Overall, it's a mess. I ended up using **both** SSO solutions. While i am slowing trying to migrate everything to Authelia, it's a long game that often requires tickets on GitHub for each service and lots of patience.+Overall, it's a mess. At least you can fully replace NGINX auth with Authelia, leveraging the support for basic auth where needed, but still lots of services have an hard time integrating with an SSO or any kind. While i am slowing trying to migrate everything to Authelia, it's a long game that often requires tickets on GitHub for each service and lots of patience.
  
 This also means that it is impossible to really have only **one** login for everything. You will have to create the user on the server, then add it to Authelia, then add it to any specific services that cannot use either. Sorry, that's life at this point. This also means that it is impossible to really have only **one** login for everything. You will have to create the user on the server, then add it to Authelia, then add it to any specific services that cannot use either. Sorry, that's life at this point.
Line 65: Line 66:
 ^ Service                                     ^ From inside       ^ From outside     ^ ^ Service                                     ^ From inside       ^ From outside     ^
 | do not require authentication               | auth not required | use SSO auth     | | do not require authentication               | auth not required | use SSO auth     |
-| Require auth, can use reverse-proxy auth    | use PAM auth      | use SSO auth     |+| Require auth, can use reverse-proxy auth    | use SSO auth      | use SSO auth     |
 | Require auth, cannot use reverse-proxy auth | use service auth  | use service auth | | Require auth, cannot use reverse-proxy auth | use service auth  | use service auth |
  
Line 73: Line 74:
 ===== Authelia SSO =====  ===== Authelia SSO ===== 
  
-First of all, follow [[services:authelia|this page]] to install the service itself+First of all, follow [[services:authelia|this page]] to install the service itself.
  
 +In order to use WebDAV, CardDAV or CalDAV, you will need to enable also basic auth on Authelia, at least for specific subdomains and locations.
 +
 +Authelia works by using the auth_request module of NGINX. The reverse proxy will first send any request to Authelia which will validate the user login. If login is successful, NGINX will then redirect the user to the correct destination page. This process is transparent once the user is logged and very fast.
 +
 +The entire process is described [[https://www.authelia.com/overview/prologue/architecture/|here]] and it's a worthwhile read.
 +
 +In order to use Authelia you need to include a few different snippets of NGINX configuration in your NGINC config files. The snippets are:
 +  * the **authelia_location** and **authelia_location-basic**
 +  * the **authelia_authrequest** and **authelia_authrequest-basic**
 +  * the **authelia_proxy**
 +
 +The **authelia_location** will create, in your domain, a specific entry point (/internal/authelia/authz/*) that will later on be used for the authentication. This snippet must be added at the server level, so that it is available only once for all the locations on the domain. You can add both the normal and the basic one at the same time.
 +
 +The **authelia_authrequest** injects in your location the redirection to the above defined entry point, and this enables the Authelia authentication for the specific location. This can be added aither to a specific location, or can be addedd at server level to have it enabled for __all__ locations within the domain. 
 +
 +The last snippet, **authelia_proxy**, simply provides some mandatory settings to pass back the authentication information , like username, to the service so that it can be used, by a service well written, to bypass it's own authentication and avoid a second layer of username/password request.
 +
 +==== Example configuration ====
 +
 +This is my **home.mydomain.com** NGINX configuration file with Authelia configured:
 +<file - home.conf>
 +server {
 +        server_name home.mydomain.com;
 +        # This listen only when accessed from outside the home network
 +        listen 8443 ssl;
 +        http2 on;
 +        # Authelia auth entry point
 +        include "com.mydomain/authelia_location.conf";
 +       # Enable Authelia login for the entire subdomain
 +        include "com.mydomain/authelia_proxy.conf";
 +        include "com.mydomain/authelia_authrequest.conf";
 +        # Include all the services under the subdomain
 +        include "com.mydomain/home/main.conf";
 +}
 +</file>
  
  
Line 116: Line 152:
  
  
 +
 +===== Specific services configuration =====
 +
 +See each service page, i wll write there any service specific details.

This website uses technical cookies only. No information is shared with anybody or used in any way but provide the website in your browser.

More information