Trusted headers, autoconnect to services

[Cherryblue]

Hi,

You might have seen me recently playing with voidauth (in particular concerning services seafile & wikijs).

While I was able to connect to these services using sso from voidauth (kind of a first win, let's admit it), I'm still unable to make it work so that if I'm already connected through voidauth, these two services automatically navigate me to the content, and show me as connected.

I suppose this is a reverse proxy problem, but I'm not an expert on the subject and kind of have already tried everything I could think of.

I'm using HAProxy and the configuration was based on what Authelia suggests.

I previously tried with authelia for the same result (which probably means yet again this isn't a voidauth problem).
But well, I still want it to work, and for that I gotta understand how it works.

After connecting directly on voidauth (no redirection invoked, for the sake of this particular test), and then browsing one of my service, I see in the cookies :

{
	"Request Cookies": {
		"x-voidauth-session-uid": "something",
		"x-voidauth-session-uid.sig": "something-else"
	}
}

I suppose there must be something helping seafile (for example) understanding that I'm already connected, and this could be it, but I see no reason for it to know "x-voidauth-session".

Is there supposed to be another cookie, header or idk, with a standard name, which would help the service knowing I'm already authenticated ?

Thanks in advance for any help, really :).

[notquitenothing]

Hello! Thank you for your docs contribution, it was appreciated!

Seafile is notable as it supports both OIDC and Trusted Header SSO Authentication. In order to have the seamless login experience, you are going to want to use the Trusted Header SSO authentication setup for Seafile, as OIDC Authentication for most Client apps will require the user to choose their login provider from a menu. Your reverse-proxy should be able to act as a gateway to make sure users are logged in to VoidAuth (this is what the x-voidauth-session-uid Header is for, HAProxy should pass that to VoidAuth where it will be verified) and pass along the ProxyAuth Result Headers from VoidAuth to Seafile. You will not see the ProxyAuth Result Headers from VoidAuth in your browser, they are passed only between HAProxy and Seafile and should include Remote-User, Remote-Email, Remote-Name, and Remote-Groups.

I don't know why Seafile wouldn't be picking up that you are already logged in though, maybe make sure it is protected by VoidAuth in HAProxy and has the REMOTE_USER_* variables set and the OAUTH_* variables not set. If that doesn't work, I will look into troubleshooting why those ProxyAuth Result Headers would not be set when you are already logged in.

[Cherryblue]

Hi again !

Thanks for your answer. I understand that trusted headers is "something else" than SSO, and so I checked the configurations you talked about, be it on you voidauth website, on authelia website, or on seafile website.

I'm still not making it :(. Here is my haproxy conf reduced to seafile, wikijs services and then voidauth :
global

    maxconn 2048
    log /dev/log local0
    stats timeout 30s
    tune.ssl.default-dh-param 2048
    ssl-default-bind-options no-sslv3
    tune.lua.bool-sample-conversion normal
    lua-load /etc/haproxy/importJSON.lua
    lua-prepend-path /etc/haproxy/http.lua
    lua-load /etc/haproxy/auth-request.lua`

defaults

    log     global
    mode    http
    option  httplog
    option  dontlognull
    option  forwardfor
    timeout connect 5s
    timeout client  50s
    timeout server  50s
    timeout tunnel  60s    # long enough for websocket pings every 55 seconds
    timeout http-request 5s  # protection from Slowloris attacks

frontend web-in

    bind :::80 v4v6
    acl host_acl path_beg /.well-known/acme-challenge/
    redirect scheme https code 301 if !host_acl !{ ssl_fc }
    use_backend letsencrypt if host_acl

frontend web-secured-in

    bind :::443 v4v6 ssl crt /certs/

    ## Trusted Proxies
    acl src-trusted_proxies src -f /etc/haproxy/trusted_proxies.src.acl
    http-request del-header X-Forwarded-For if !src-trusted_proxies

    ## Ensure X-Forwarded-For is set for the auth request.
    acl hdr-xff_exists req.hdr(X-Forwarded-For) -m found
    http-request set-header X-Forwarded-For %[src] if !hdr-xff_exists
    option forwardfor

    ## Auth process
    acl host_auth hdr(host) -i auth.my.domain
    acl protected_services hdr(host) -m reg -i ^(?i)(wiki|hub)\.my\.domain

    # Verify URLs
    acl host_seafile hdr(host) -i hub.my.domain
    acl host_wiki hdr(host) -i wiki.my.domain
    
    # Required Headers
    http-request set-var(req.scheme) str(https) if { ssl_fc }
    http-request set-var(req.scheme) str(http) if !{ ssl_fc }
    http-request set-var(req.questionmark) str(?) if { query -m found }

    http-request set-header X-Forwarded-Method %[method]
    http-request set-header X-Forwarded-Proto  %[var(req.scheme)]
    http-request set-header X-Forwarded-Host   %[req.hdr(Host)]
    http-request set-header X-Forwarded-URI    %[path]%[var(req.questionmark)]%[query]

    ## SSO Intercepting services    Backend name    Path                    Method  Request Success                                                 Failure Condition
    http-request lua.auth-intercept voidauth        /api/authz/forward-auth HEAD    *       remote-user,remote-groups,remote-name,remote-email      -       if protected_services
    http-request deny if            protected_services              !{ var(txn.auth_response_successful) -m bool } { var(txn.auth_response_code) -m int 403 }
    http-request redirect location %[var(txn.auth_response_location)] if protected_services !{ var(txn.auth_response_successful) -m bool }
    use_backend voidauth if host_auth

    # Services Backends
    use_backend seafile if host_seafile
    use_backend wiki if host_wiki

backend voidauth

    server voidauth 127.0.0.1:3001

backend seafile

    server seafile 127.0.0.1:42000 check

backend wiki

    server wiki 127.0.0.1:3333 check

backend letsencrypt

    server nginx_internal 127.0.0.1:54321

On seafile side, I disabled SSO & LDAP conf (I mainly used ldap at the moment so my real accounts are on it..), and added the conf variables and mapping I could find on this and this :

    ENABLE_REMOTE_USER_AUTHENTICATION = True
    REMOTE_USER_CREATE_UNKNOWN_USER = True
    REMOTE_USER_ACTIVATE_USER_AFTER_CREATION = True
    REMOTE_USER_HEADER = 'Remote-User'
    REMOTE_USER_ATTRIBUTE_MAP = {
            'Remote-Name': 'name',
            'Remote-Email': 'contact_email',
    }

The behavior didn't change, I still land on seafile login screen :(.

That set aside, I do suggest to add a haproxy guide on your website once this case is working.

[notquitenothing]

I will take a look and see if I can get it working, thanks for being so thorough!