[Feature Request] Widgets (etc) showing based on SSO groups #3782
Replies: 2 comments
-
I've implemented this exact feature in my fork here: homepage I put in a PR about 4-6 months ago and it was rejected - but I'd like to restart the discussion of the feature request as it has been brought up SEVERAL times in different places. |
Beta Was this translation helpful? Give feedback.
0 replies
-
This discussion has been automatically closed due to lack of community support. See our contributing guidelines for more details. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Description
My homelab setup has Traefik and Keycloak, which combined with an oauth2-proxy config sends Keycloak group membership in a header back to/through the reverse proxy. With this config, the user logging in gets a header filled like this, with the names of the groups he's a member of:
X-Auth-Request-Groups: /access-cockpit,/access-guacamole,/access-application,/access-whoami
Request: I wonder if it would be easy to implement a feature which allows me to specify the name of a header in my Homepage config and then, have Homepage do a regex of the value of that header, against the a group name string on the service, to see if there are matches? Target being that only the matching apps with group names represented in the header, would have the marked widget showing. (Specifying the header name might be essential - I believe different apps like Authentik send different header names back to the Proxy)
If my user is not a member of
access-application
, traefik/oauth2-proxy/keycloak prevent them getting access through the proxy in the usual way - this is not what I ask of Homepage. This suggestion is just preventing a widget being seen in Homepage when they are not a member of the group (and therefore don't have access to the app).Other
For interest, the build template I roughly followed is here and with a bit more effort elsewhere around the groups. If you follow this plan and get weird results, be sure not to put any iframe blocking in any Traefik middleware config using the 'default' middleware method. Those default configs don't get overridden - and Keycloak depends on hidden iframes to function. (a bug /or feature of Traefik that cost me a lot of time.)
The
/
and,
have not been added by me in the UI, so I guess they must be separators as added by the app. For my Traefik config to become group aware, I ended up needing to add the extra/
in the oauth2 query configuration. (Although not the comma.) I named my groups with the "access-app" naming convention - "access-" prefix might seem longwinded, but noting this just to say the prefixaccess
wasn't added by any of the software components.I love this app either way, this is just a thought! Thank you!
Beta Was this translation helpful? Give feedback.
All reactions