Synology DSM (and apps) with Authelia

[helmut72]

If someone also need this setup. This example makes the following assumptions:

Synology Root URL: https://dsm.example.com
Authelia Root URL: https://auth.example.com
Client ID: diskstation
Client Secret: diskstation_client_secret

In DSM go to Control Panel -> Domain/LDAP -> SSO-Client. Enable OpenID Connect SSO service and use these settings:

Profile: OIDC
Name: Authelia (or anything else, it's just the non-technical display name)
Wellknown URL: https://auth.example.com/.well-known/openid-configuration
Application ID: diskstation
Application key: diskstation_client_secret
Redirect URL: https://dsm.example.com
Authorization Scope: openid profile groups email
Username claim: preferred_username

In Authelia use this configuration:

      - id: diskstation
        description: Diskstation
        secret: diskstation_client_secret
        public: false
        authorization_policy: one_factor
        scopes:
          - openid
          - profile
          - groups
          - email
        redirect_uris:
          - https://dsm.example.com

Both, Synology DSM and Authelia runs behind a reverse proxy. Synology DSM is connected to the same LDAP server that also Authelia use. I think my biggest mistake was an empty Authorization Scope field in DSM.

[james-d-elliott]

Check this out: https://deploy-preview-4167--authelia-staging.netlify.app/integration/openid-connect/synology-dsm/

If you could check that looks fine that'd be good. Also a cropped screenshot with the exact settings from the article in the UI would be nice.

#4167

[helmut72]

Looks good for me. Only two typos: Application ID: synolgoy-dsm is Application ID: synology-dsm and secret: synolgoy-dsm_client_secret is secret: synology-dsm_client_secret.

Maybe it should be mentioned that LDAP is also needed on Synology.

I was brave and deleted my whole LDAP config, but Synology DSM doesn't create any user automatically after a successful login with OIDC. I think a local user with the same username must be created in advance if there is no LDAP configured. But I wasn't brave enough to try this out too. It's my productive system and don't want to restore if anything goes crazy.

Here is a screenshot with your used data:

[webysther]

Looks good for me. Only two typos: Application ID: synolgoy-dsm is Application ID: synology-dsm and secret: synolgoy-dsm_client_secret is secret: synology-dsm_client_secret.

Maybe it should be mentioned that LDAP is also needed on Synology.

I was brave and deleted my whole LDAP config, but Synology DSM doesn't create any user automatically after a successful login with OIDC. I think a local user with the same username must be created in advance if there is no LDAP configured. But I wasn't brave enough to try this out too. It's my productive system and don't want to restore if anything goes crazy.

Here is a screenshot with your used data:

The note about domain is important to have, after all configuration I discovered this limitation. The flow works and fail in the end, shame for Synology.

[blysik]

I've been trying to set this up in DSM 7.1. I enter the information in the DSM UI as noted in the doc, and this thread, and hit save. However, the DSM doesn't appear to be able to hit the .well-known url and retrieve the 2 endpoints:

Does the Redirect URI have to use a real domain? I can go back to reverse proxying my DSM if necessary, but I was trying that before, with same results.

When I try to login via SSO, I get the error from DSM login: Unable to get the URL for SSO authentication.

[james-d-elliott]

Sounds like the DNS is not resolving the URL to the nginx proxy (container or otherwise)

[blysik]

I can't figure out if it's a DNS issue, or some other networking problem. I opened up an issue with more details of the commands that work, don't work, with the SWAG folks: linuxserver/docker-swag#350

Let me think about it from a DNS perspective.

[james-d-elliott]

This is very unlikely to be an issue on their end. I'd start by checking what DSM resolves the authelia domain to.

[blysik]

Super appreciate you continuing to think about this problem. (Since it doesn't really appear to be an authelia issue.)

My Synology has cloudflare DNS as its resolver, 1.1.1.1. On the shell, I can nslookup auth.mydomain.com properly, and it shows my external IP given by the ISP. I enabled logging on my firewall, for the port forward to SWAG's 9443. I can see NAS -> Firewall -> port forward to NAS port 9443.

My nginx rule at that point would use the IP of the authelia host, so DNS wouldn't be a factor, I don't think. This is a head scratcher.

[blysik]

For now, I've side-stepped my problem by just moving SWAG reverse-proxy off of my NAS, to another system. Synology DSM can now hit the .well-known url. However, it seems like I really do need to setup LDAP, even though I'm using a user with the same name as local on Synology and in Authelia.

[blysik]

Both, Synology DSM and Authelia runs behind a reverse proxy. Synology DSM is connected to the same LDAP server that also Authelia use. I think my biggest mistake was an empty Authorization Scope field in DSM.

Hi @helmut72 ! Can you provide the config you use for putting DSM behind a reserve proxy? I have this setup as well, using nginx, but I'm wondering if what I'm doing isn't good enough for this use case. Thanks!

[helmut72]

Nothing special. I use Caddy:

dsm.example.com:443 {
       reverse_proxy http://ip.of.syno.logy:5000
}

Do you have LDAP enabled and configured in DSM?

[helmut72]

Great! I also don't understand why Synology doesn't accept or create local users when using OIDC. They just need to create a local password for services, that doesn't support OIDC.

[blysik]

From my reading in this world, vendor implementations are all over the place. Also, helmut72, I notice that I can't make an LDAP user a "full" admin of the NAS . I guess this is by design, and a bit unfortunately. I was hoping I could stop logging in via the local admin user completely.

[scrapix]

Thank your folks for the explanations and discussions. With those I came as far as being able to display Authelias Log-In pop-up and thereafter Authelias consent request when trying to log into synology photos via SSO.

Unfortunately I'm getting an error though, and the login request won't be passed through:
Access Request failed with error: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). the passwords don't match

Is there anyone who has a clue what I might be missing?

authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '256a4b8e-382d-4b22-a230-8e59ede4f8c0' on client with id 'synology-dsm' is being processed",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:22+01:00"
}
authelia | {
	"level": "debug",
	"method": "POST",
	"msg": "Mark 1FA authentication attempt made by user 'test'",
	"path": "/api/firstfactor",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:32+01:00"
}
authelia | {
	"level": "debug",
	"method": "POST",
	"msg": "Successful 1FA authentication attempt made by user 'test'",
	"path": "/api/firstfactor",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:32+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '3800e86b-2d90-4498-9624-8e06b59b646e' on client with id 'synology-dsm' is being processed",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:33+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '3800e86b-2d90-4498-9624-8e06b59b646e' on client with id 'synology-dsm' using consent mode 'explicit' proceeding to generate a new consent session",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:33+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '3800e86b-2d90-4498-9624-8e06b59b646e' on client with id 'synology-dsm' using consent mode 'explicit' authentication level 'one_factor' is sufficient for client level 'one_factor'",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:33+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '3800e86b-2d90-4498-9624-8e06b59b646e' on client with id 'synology-dsm' using consent mode 'explicit' is being redirected to 'https://auth.MyDomain.com/consent?id=e2db9b16-a5ae-41da-9773-50c1bb494f40'",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:33+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '21145b93-7b5d-4c90-b6ce-53312d302dba' on client with id 'synology-dsm' is being processed",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:35+01:00"
}
authelia | {
	"level": "debug",
	"method": "GET",
	"msg": "Authorization Request with id '21145b93-7b5d-4c90-b6ce-53312d302dba' on client with id 'synology-dsm' was successfully processed, proceeding to build Authorization Response",
	"path": "/api/oidc/authorization",
	"remote_ip": "92.116.xx.xxx",
	"time": "2023-11-14T22:41:35+01:00"
}
authelia | {
	"level": "error",
	"method": "POST",
	"msg": "Access Request failed with error: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). the passwords don't match",
	"path": "/api/oidc/token",
	"remote_ip": "92.116.xx.xxx",
	"stack": [{
		"File": "github.com/authelia/authelia/v4/internal/handlers/handler_oidc_token.go",
		"Line": 27,
		"Name": "OpenIDConnectTokenPOST"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/http_to_authelia_handler_adaptor.go",
		"Line": 113,
		"Name": "NewHTTPToAutheliaHandlerAdaptor.func1"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/bridge.go",
		"Line": 54,
		"Name": "(*BridgeBuilder).Build.func1.1"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/headers.go",
		"Line": 35,
		"Name": "SecurityHeadersNoStore.func1"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/headers.go",
		"Line": 25,
		"Name": "SecurityHeadersCSPNone.func1"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/headers.go",
		"Line": 16,
		"Name": "SecurityHeaders.func1"
	}, {
		"File": "github.com/authelia/authelia/v4/internal/middlewares/cors.go",
		"Line": 216,
		"Name": "(*CORSPolicy).Middleware.func1"
	}, {
		"File": "github.com/fasthttp/router@v1.4.14/router.go",
		"Line": 414,
		"Name": "(*Router).Handler"
	}, {
		"File": "github.com/valyala/fasthttp@v1.43.0/http.go",
		"Line": 154,
		"Name": "(*Response).StatusCode"
	}, {
		"File": "github.com/valyala/fasthttp@v1.43.0/server.go",
		"Line": 2338,
		"Name": "(*Server).serveConn"
	}, {
		"File": "github.com/valyala/fasthttp@v1.43.0/workerpool.go",
		"Line": 224,
		"Name": "(*workerPool).workerFunc"
	}, {
		"File": "github.com/valyala/fasthttp@v1.43.0/workerpool.go",
		"Line": 196,
		"Name": "(*workerPool).getCh.func1"
	}, {
		"File": "runtime/asm_amd64.s",
		"Line": 1594,
		"Name": "goexit"
	}],
	"time": "2023-11-14T22:41:36+01:00"
}

[james-d-elliott]

Try ensuring the secret is only alphanumeric characters.

[scrapix]

@james-d-elliott thank you tons for your quick reply! you made my night!
While the Client Secret / Application Secret does not have to be only alphanumeric, I found out that my Client Secrets did not match because I've tried to put my Client Secret as an environment variable / secret into authelias config. I've noticed that this does not work.
Now the client secret lives in plain text within the config file but logging into DSM Services works!

[Karstensson]

Has anyone managed to get it working with the photos and drive apps as well? I can only get it working using one of the services. If I add more than one Redirect URI in synology it fails. To clarify I have three subdomains, nas.domain.com, photos.domain.com and drive.domain.com. Authelia is configured to have all three as well. The first sign in can be done in any of the tree domains, but if I try to sign in later to any of the other services I get the following error. `The 'redirect_uri' from this request does not match the one from the authorize request.

  oidc:
    hmac_secret: Secret
    issuer_private_key: |
      -----BEGIN RSA PRIVATE KEY-----
      -----END RSA PRIVATE KEY-----
    access_token_lifespan: 1h
    authorize_code_lifespan: 1m
    id_token_lifespan: 1h
    refresh_token_lifespan: 90m
    enable_client_debug_messages: false
    enforce_pkce: public_clients_only
    cors:
      endpoints:
        - authorization
        - token
        - revocation
        - introspection
      allowed_origins_from_client_redirect_uris: false    
    clients:
      - id: synology-dsm
        description: Synology DSM
        secret: 'Secret'
        public: false
        authorization_policy: one_factor
        redirect_uris:
          - https://nas.domain.com
          - https://photos.domain.com
          - https://drive.domain.com
        scopes:
          - openid
          - profile
          - groups
          - email
        userinfo_signing_algorithm: none
        consent_mode: pre-configured
        pre_configured_consent_duration: 1y´´´

[Karstensson]

Thanks for the quick reply. I will try that then. But this is due to a Synology issue rather than Authelia right?

[helmut72]

Sorry, don't know and don't wanted to start investigation, because path style is also ok for me.

[james-d-elliott]

There is almost zero chance this specific issue is an Authelia one. I've used several apps with multiple redirect URIs, as long as they request the right one it works flawlessly.

[Karstensson]

Thanks for the responses!

[scrapix]

I've had the same issue and want to try authentik in the next weeks, to see if that'll work better.

[Jeppedy]

Whoa, am I understanding that it is not enough to set up OIDC, but I ALSO need to configure LDAP on Synology as well? I've got OIDC working great for a number of applications. But for Synology, it returns no user ID from Authentik. It replies with an Invalid Account or Password error.
I'm seeing reference here and there to LDAP needing to be set up. Do I need to configure LDAP on Synology to ALSO point to Authentik?

[helmut72]

You need to point LDAP client on Synology to a LDAP server with at least the exact same usernames and properties.

[lbalogh]

No you don't need to configure LDAP on the Synology, you can select Domain/LDAP/local in the OpenID Connect SSO settings dialog :

Which works with local DSM accounts

[helmut72]

Then you need to manage user accounts on more than one place.

[lbalogh]

Sure, but it depends how many users you manage. In MY personal case, I'm the only one who access my Synology (and my homelab services in general). In Authelia I'm using the file authentication backend with 1 user, switching to LDAP would be overkill.

I was just saying it's possible, of course it's not a good idea to have local authentication for more than a handful of users.

Cheers

[helmut72]

Thanks for sharing. Maybe I have seen this option while setup my diskstation, but never gave a second thought to use this.

[jonrasp]

@lbalogh
Where is this option? I only get these:

Did you need to install any extra services onto DSM?

No you don't need to configure LDAP on the Synology, you can select Domain/LDAP/local in the OpenID Connect SSO settings dialog :

Which works with local DSM accounts

[lbalogh]

No I did not install extra services. The account type field has always been there for me :

What is your DSM version ? I'm on 7.2.1-69057 Update 4

[DennisGaida]

This is a new feature of DSM 7.2 (being able to select the account type)

[DennisGaida]

In have updated the documentation on this point: #7133

[jonrasp]

Thanks both. I've just updated my instance of DSM and it works exactly as you've described.