[QUESTION] OIDC User and Group Admin differentiation

[dasunsrule32]

Question

Is there a way to differentiate admins and users when using OIDC? Is it possible to assign a configuration of type: admin to an OIDC user or group? Not sure if that is implemented or not. Thank you.

@twsouthwick

Category

Authentication

Please tick the boxes

• [X] You are using a supported version of Dashy (check the first two digits of the version number)
• [X] You've checked that this question hasn't already been raised
• [X] You've checked the docs and troubleshooting guide
• [X] You agree to the code of conduct

[dasunsrule32]

Is there a way to get DEBUG logs to dump to the container logs? I'm trying to dump exactly what is being consumed by Dashy when an OIDC account logs in. Maybe I can try assigning a type to what Dashy sees the email, username, etc as a type: admin. Might work..

[CrazyWolf13]

For me it always worked to intercept the URL from auth-server right before logging in into dashy, then you can decode this with I think https://jwt.io/ and you will see which data gets provided to dashy

Edit: this is not working for me for dashy, possibly due to the public client in the oidc specs, sorry.

[dasunsrule32]

I looked at the code and the default scope is: openid profile email roles groups. So the data is definitely there as long as it isn't overwritten by a custom scope in the conf.yml.

https://github.com/Lissy93/dashy/blob/master/src/utils/OidcAuth.js#L23

With the way I configured it in the docs, the following is a sample of data being sent to Dashy from authentik:

{
    "iss": "https://auth.domain.com/application/o/dashy/",
    "sub": "*********************",
    "aud": "************************",
    "exp": **********,
    "iat": *************,
    "auth_time": *****************,
    "acr": "goauthentik.io/providers/oauth2/default",
    "amr": [
        "user",
        "mfa"
    ],
    "email": "[email protected]",
    "email_verified": true,
    "name": "Test User",
    "given_name": "Test User",
    "preferred_username": "test",
    "nickname": "test",
    "groups": [
        "authentik Admins",
        "Cloudflare Users",
        "pgAdmin Admins",
        "KASM Admins",
        "TrueNAS SCALE Admins",
        "Mealie Admins",
        "Mealie Users",
        "Dashy Admins"
    ]
}

[Tooloco]

Hello, I am also wondering this especially for the config option "disableConfigurationForNonAdmin". As im using OIDC with Authentik I have no idea where the property "type: admin" is being read from. Any further info would be appreciated. Thank you

[jlbnetwork]

I’m using Dashy with OIDC (via Authentik) and running into the issue where disableConfigurationForNonAdmin: true doesn’t restrict config access (all users logged in via OIDC can still edit).

I can’t use the users: block either, since that triggers the built-in login and breaks OIDC.

Is there any way to make Dashy treat certain OIDC users (e.g., by group) as non-admins or enforce read-only mode selectively?

[dasunsrule32]

No, but you can use Authentik groups to set visibility. See the docs that I wrote in the main branch.

https://github.com/Lissy93/dashy/blob/master/docs/authentication.md#authentik

[jlbnetwork]

Thanks! I’ve followed that exact procedure in the documentation — I’m using OIDC via Authentik and assigning users to different groups. I have one group (for admin access) that includes only myself, and another group for standard users.

The hideForKeycloakUsers feature works well for controlling visibility of sections and items. However, what I’m trying to achieve is restricting access to Dashy’s configuration editor — making the dashboard read-only for regular users, while retaining full editing access for myself.

Currently, disableConfigurationForNonAdmin doesn’t seem to apply when using OIDC. And if I use the users: block to define admin roles, it disables the OIDC flow and triggers the built-in login prompt instead.

[dasunsrule32]

There's not a good way to do that currently. I just disable configuration entirely and only do it via the yaml configs.

  disableConfiguration: true

[HolyMacarony]

Thanks! I’ve followed that exact procedure in the documentation — I’m using OIDC via Authentik and assigning users to different groups. I have one group (for admin access) that includes only myself, and another group for standard users.

The hideForKeycloakUsers feature works well for controlling visibility of sections and items. However, what I’m trying to achieve is restricting access to Dashy’s configuration editor — making the dashboard read-only for regular users, while retaining full editing access for myself.

Currently, disableConfigurationForNonAdmin doesn’t seem to apply when using OIDC. And if I use the users: block to define admin roles, it disables the OIDC flow and triggers the built-in login prompt instead.

Good evening! Would you please be so nice and show me how you managed to hide/show apps on a group/role basis with dashy?

I have roles and groups setup in keycloak, but no matter what I try, I cannot create different dashboards for users on a basis of groups/roles.

In my dashy config I have this oidc config which works so far. One user having the "admin" group in keycloak can edit the config file of dashy and another user opens dashy as non admin user:

auth:     
   enableOidc: true
   oidc:
     adminRole: admin
     adminGroup: admin
     clientId: dashy
     endpoint: https://keycloak.<DOMAIN>/realms/<REALMNAME>

But when it comes to restriction, it simply does not work. E.g. I have this to only show a section to my admin user, but it is not shown at all to any user. Roles/Groups are ignored. How did you succeed here?

  - name: Authentication
    displayData:
      sortBy: default
      rows: 2
      cols: 1
      collapsed: false
      hideForGuests: true
      showForKeycloakUsers:
        groups: 
          - admin
    items:
      - title: Immich
        icon: immich.svg
        url: https://immich.<DOMAIN>
        target: newtab
        id: 0_1472_authentikadmin
        displayData:
          hideForKeycloakUsers:
            roles:
              - use-immich

Thank you very much for your time!