this post was submitted on 18 Mar 2025
85 points (96.7% liked)

Selfhosted

61475 readers
1200 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

What are you folks using for self-hosted single sign-on?

I have my little LDAP server (lldap is fan-fucking-tastic -- far easier to work with than OpenLDAP, which gave me nothing but heartburn). Some applications can be configured to work with it directly; several don't have LDAP account support. And, ultimately, it'd be nice to have SSO - having the same password everywhere if great, but having to sign in only once (per day or week, or whatever) would be even nicer.

There are several self-hosted Auth* projects; which is the simplest and easiest? I'd really just like a basic start-it-up, point it at my LDAP server, and go. Fine grained ACLs and RBAC support is nice and all, but simplicity is trump in my case. Configuring these systems is, IME, a complex process, with no small numbers of dials to turn.

A half dozen users, and probably only two groups: admin, and everyone else. I don't need fancy. OSS, of course. Is there any of these projects that fit that bill? It would seem to be a common use case for self-hosters, who don't need all the bells and whistles of enterprise-grade solutions.

you are viewing a single comment's thread
view the rest of the comments
[–] keyez@lemmy.world 8 points 1 year ago (2 children)

I used to run key cloak backed by LDAP. Few months ago moved to Authelia and after many hours of tinkering and setting up sites I haven't had to touch it except to add a new URL or user.

I slightly disagree with the other commenter I didn't find it easy or straightforward but once I finally found what worked for my setup its been great.

Imagine Authelia is the caddy of SSO. Powerful, intimidating but very efficient. Also all configs are in like 3 files and things aren't going to change without FS access which only I the admin have.

[–] scrubbles@poptalk.scrubbles.tech 2 points 1 year ago (2 children)

I've tried and failed a couple of times, would you mind sharing (or dming) your example config? Maybe I'm just a been with sso and can't figure it out

[–] keyez@lemmy.world 2 points 1 year ago (1 children)

Certainly, I'll post it tomorrow

[–] keyez@lemmy.world 1 points 1 year ago

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: authelia@authelia.com
    groups:
      - admins
      - dev
  user001:
    disabled: false
    displayname: 'User 001'
    password: "$6$rounds=50000$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    email: test@gmail.com
    groups:
      - admins
      - users
[–] sxan@midwest.social 2 points 1 year ago

Caddy is anything but intimidating! If Authelia is anything like Caddy in ease of use, sign me up!