Self-hosted SSO

[email protected]

LLDAP + Authelia

I actually moved from Authentik to Authelia because it was easier for me to add a couple of lines to a yaml than to navigate Authentik's web ui. Authentik is more feature-full but I'm only running SSO for myself and a couple of others at home.

[email protected]

Sounds like you need to talk with @[email protected] from elsewhere in this comment section.

[email protected]

Thanks a lot!

[email protected]

No problem. Thanks for the reminder that just because he's the first thing I see when I search Authentik on YouTube doesn't mean that's what you get.

[email protected]

It juat doesnt wirk in Firefox (mobile android)

[email protected]

If you want to keep your LDAP as the source of truth, then Keycloak is also a very good option. I did that originally, but decided I only had a couple of things needing LDAP and that wasn't worth keeping it around. Authentik was a good way to emulate an LDAP but with a different back end. But Keycloak is definitely my recommendation in your case.

[email protected]

Heres what I'm running:

authentication_backend:
  file:
    path: '/config/users_database.yml'
    watch: false
    search:
      email: false
      case_insensitive: false
    password:
      algorithm: 'sha2crypt'

access_control:
  ## Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'. It is the policy applied to any
  ## resource if there is no policy to be applied to the user.
  default_policy: 'deny'

  networks:
    - name: 'internal'
      networks:
        # - '10.10.0.0/16'
        - '192.168.1.0/24'
    - name: 'VPN'
      networks: '10.0.1.0/24'

  rules:
    ## Rules applied to everyone
    - domain: '*.mydomain.com'
      policy: 'one_factor'

session:
  ## The secret to encrypt the session data. This is only used with Redis / Redis Sentinel.
  ## Secret can also be set using a secret: https://www.authelia.com/c/secrets
  secret: 'insecure_session_secret'

  ## Cookies configures the list of allowed cookie domains for sessions to be created on.
  ## Undefined values will default to the values below.
  cookies:
  #   -
      ## The name of the session cookie.
    - name: 'authelia_session'

      ## The domain to protect.
      ## Note: the Authelia portal must also be in that domain.
      domain: 'mydomain.com'

      ## Required. The fully qualified URI of the portal to redirect users to on proxies that support redirections.
      ## Rules:
      ##   - MUST use the secure scheme 'https://'
      ##   - The above 'domain' option MUST either:
      ##      - Match the host portion of this URI.
      ##      - Match the suffix of the host portion when prefixed with '.'.
      authelia_url: 'https://auth.mydomain.com/'
storage:
  postgres:
    ....

identity_providers:
  oidc:
    ## Cross-Origin Resource Sharing (CORS) settings.
    cors:
      ## List of endpoints in addition to the metadata endpoints to permit cross-origin requests on.
      endpoints:
         - 'authorization'
         - 'token'
         - 'revocation'
         - 'introspection'
        #  - 'pushed-authorization-request'
        #  - 'userinfo'

      ## List of allowed origins.
      ## Any origin with https is permitted unless this option is configured or the
      ## allowed_origins_from_client_redirect_uris option is enabled.
      allowed_origins:
        - 'https://mydomain.com/'
        - 'https://grafana.mydomain.com/'
        - 'https://wiki.mydomain.com/'
        - 'https://foodz.mydomain.com/'

      ## Automatically adds the origin portion of all redirect URI's on all clients to the list of allowed_origins,
      ## provided they have the scheme http or https and do not have the hostname of localhost.
      allowed_origins_from_client_redirect_uris: true
    ## Clients is a list of known clients and their configuration.
    clients:
      - client_id: 'grafana'
        client_name: 'Grafana'
        client_secret: 'XXXXXX'
        public: false
        consent_mode: 'pre-configured'
        authorization_policy: 'one_factor'
        require_pkce: true
        pkce_challenge_method: 'S256'
        redirect_uris:
          - 'https://grafana.mydomain.com/login/generic_oauth'
        scopes:
          - 'openid'
          - 'profile'
          - 'groups'
          - 'email'
        userinfo_signed_response_alg: 'none'
        token_endpoint_auth_method: 'client_secret_basic'
      - client_id: 'wiki'
        client_name: 'Wiki'
        client_secret: 'XXXX'
        consent_mode: 'pre-configured'
        public: false
        authorization_policy: 'one_factor'
        require_pkce: true
        pkce_challenge_method: 'S256'
        redirect_uris:
          - 'https://wiki.mydomain.com/oidc/callback'
        scopes:
          - 'openid'
          - 'profile'
          - 'groups'
          - 'email'
        userinfo_signed_response_alg: 'none'
        token_endpoint_auth_method: 'client_secret_basic'
      ....

Then my users_database.yml looks like:

users:
  authelia:
    disabled: false
    displayname: "Test User"
    password: ""
    email: [email protected]
    groups:
      - admins
      - dev
  user001:
    disabled: false
    displayname: 'User 001'
    password: "$6$rounds=50000$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    email: [email protected]
    groups:
      - admins
      - users

[email protected]

Yeah, that sounds ideal. I'd prefer editing a file than administering through a web page.

I'm checking Authelia right now.

SSO is part, but not all, of the picture. There's also multi-system passwords, for things like sudo, and non-web service authentication; most of the stuff like OAUTH is really hacky to make work outside of web environments.

I've considered Vault for some of the inter-service authentication, but there's not broad support built into services and it's yet another thing to mess with.

LDAP forms a good base for most use cases, and so keeping it as the source of truth is important for me. And then, as few other layers on top to get SSO. Authelia is looking like the best solution.

[email protected]

If Pocket ID and Passkeys are like most modern "solutions", they ignore everything that isn't web, or human. Have you hooked any services together using it? Like having Home Assistant authenticate against mpd?

? Offline

Passkeys work on whatever platforms your passkey is compatible with. I store mine in my BitWarden vault which works on web/PC/mobile just fine.

Pocket ID is an OpenID Connect provider (basically OAuth), so it depends on whichever apps you're using having support for that.

Home Assistant does not natively support OIDC, but there is a community project in active development which aims to add support.

[email protected]

Kerberos, you say? Single sign-on?

Have you heard about the LDAP and Kerberos configured as part of setting up samba4ad?

I accidentally enabled SSO SSH a few years back. My samba units aren't on PIs but they could be. They're just on tiny tiny VMs.

[email protected]

I just tested my version of Firefox (Fresh from Play Store) and it worked without issues on my end to login to the server.

The only browser I'm aware of which doesn't support it is the Duck Duck Go Browser which is a shame. They don't seem to care about enabling WebAuthn support.

[email protected]

I have several services. Home Assistant is not one as it's still a WIP for the person who's developing a solution. It works, but I'm sort of holding off until I can test it more with the mobile app.

https://github.com/christiaangoossens/hass-oidc-auth

But, to answer your question:
I log into Tailscale with it.
I also have it connected to Proxmox and Portainer
Additionally, I have it connected to Pomerium so I can log into my FreshTomato Router with a fingerprint
I also have a self hosted PasteBin connected to it.

[email protected]

I am using a Pixel 7 Pro and disabled the Google Passwortmanager and set Bitwarden as my preferred manager.
So either Google did something, Firefox can't reach some ressource or I didnt configure something correctly.

? Offline

For my web ui apps I just use traefik forward auth with Google. Works great for my use case

[email protected]

So... you have applications that aren't web apps, authenticating themselves with other applications that aren't web applications? Not proxying for you, but literally connecting to do something, like perform a backup.

[email protected]

Don't you threaten me with Kerberos. I used to have to deal with that crap decades ago; I disliked it then, and unless it's gotten dramatically easier to work with, it's not an option for me now.

I hadn't heard specifically about samba4ad, but Kerberos on LDAP (and, originally, I think, on OLAP) I'm familiar with.

I like LDAP in concept, but after using OpenLDAP for a few years when my network evolved OpenLDAP evolved out of it. It may have been secure, but a more horribly, difficult to debug piece if software, I've rarely met. LLDAP has changed all that, and allowed me to start using LDAP again; it may be less capable, but OpenLDAP was overkill for home gamers. LLDAP is juuuust right.

Accidentally enabling SSO sounds like a big fish tale. SSO of usually a PITA to configure and set up. Even commercial software offerings are byzantine.

[email protected]

This is where I get stuck. I've worked with OAuth before, and it is very web-centric. Maybe it's possible to work around http connections, but everything I've read makes it clear that it was designed with web applications - and browsers - as the foundational concept.

For example, I have a memory of trying to get two servers - neither of which had anything to do with the web - to authenticate, and to use OAuth I remember having to import an http library.

It's been an age, so I may not be remembering it correctly; but IIRC the OAuth flow is designed around web protocols.

agnos.is Forums

Self-hosted SSO