Feature Request: Rules based on groups claims

[dirtycajunrice]

Currently, the only way to restrict a pool of users is via either having separate domain.tld emails, or to individually define them. Allowing the ability to reference a user-defined scope would enable flexibility of permissions. For example: Default oauth2 would have a groups top level in the token where you could allow users/application_name/read or users/application_name/* etc. User-defined would be the same as above but being able to define what/where that "groups" attribute is. e.g. cognito uses the claim cognito:groups instead of the top level.

Thanks for tfa!

[thomseddon]

Hey, it's good to see this has picked up some support - could you clarify what's being proposed here, "groups" aren't part of the oauth2 spec, so I believe this would need a per-provider setup.

I'd like to implement generic support for group based authentication - so if you could clarify if that's what you meant, or what you meant if not - that would be appreciated :)

NTS: Open issue for generic group support if this isn't that

[zenjabba]

yes, I expect it will need to be specific to each service, but you could incorporate something like this https://stackoverflow.com/questions/16601699/determine-whether-user-is-group-member for google specifically to check if a user is part of a group

[belfhi]

I would love if this could be integrated. This is already a great project and including claims would be very useful. I would suggest that the claim should be a configuration option, especially since groups is non-standard. Similar to how TraefikEE allows authorization with pics, tbh.

[snowzach]

I was looking at OAuth2_Proxy for this functionality: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#google-auth-provider

It uses a service account to fetch group membership information. I may try to add support for this if you help me get started. I am thinking some sort of group interface for each provider type. If you guys want to stub out the interface spec and where it goes, I might try to add support for it for the Google provider to start with.

I assume it would be something along the lines of GroupIsMember(user, group string) (bool, error) implemented on each provider and then the implementation can be up to the provider. The google configuration would include the service account and calling that might go out to google and check the user for group membership.

[dystopiandev]

@DirtyCajunRice @snowzach any updates or alternatives?

[dirtycajunrice]

@dystopiandev This is something that I have in my backlog to implement. It has not made it to my active list yet but hopefully soon. I promise to update as I have it!

[kboshold]

This feature would be very helpful for me as well. If you look at the oauth2 proxy for example, there is also the possibility to set groups (i.e. for keycloak): https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#keycloak-auth-provider

Of course, you should be able to set this differently per service. api.example.com => Only users inside "API Group" status.example.com => All users (logged in)

[cheald]

I've implemented this in my fork - https://github.com/cheald/traefik-forward-auth/tree/roles-support

I've added a few other things that I've seasoned to my own personal taste, so the branch isn't quite in shape for a pull request, but feel free to pick from it as necessary. Right now it looks for a hardcoded groups claim (because I am using it with Keycloak, and can set that claim up easily enough) but with a bit more work the claim could perhaps be made configurable.

[pengu-fr]

I've implemented this in my fork - https://github.com/cheald/traefik-forward-auth/tree/roles-support

I've added a few other things that I've seasoned to my own personal taste, so the branch isn't quite in shape for a pull request, but feel free to pick from it as necessary. Right now it looks for a hardcoded groups claim (because I am using it with Keycloak, and can set that claim up easily enough) but with a bit more work the claim could perhaps be made configurable.

This is just perfect ! I've build a docker image from your fork and it just worked ! Thank you for this ! I hope someone could implemented your code into the master branch !

I've reconfigured my docker-compose.yml with : command: --rule.user.action=auth --rule.user.provider=oidc --rule.user.groups=simple-user --rule.user.groupmode=any --rule.user.rule=!PathPrefix(`/admin`) --rule.admin.action=auth --rule.admin.provider=oidc --rule.admin.groups=administrator --rule.admin.groupmode=any --rule.admin.rule=PathPrefix(`/admin`)

So users from "simple-user" group can acces all the application except the "/admin" part. And the users from the "administrator" group can acces the "/admin" part.

[karma-git]

@cheald, @pengu-fr,

Hello! Guys, could you please help me to implement this fork?

In keykloak I created a client and group, assign user to group. Created standart mapper groups for client. But it didn't help - random user from realm still could autentificate to app =/.

Thank you!

deployment

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik-forward-auth
  namespace: stage
  labels:
    app: traefik-forward-auth
spec:
  selector:
    matchLabels:
      app: traefik-forward-auth
  template:
    metadata:
      labels:
        app: traefik-forward-auth
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - image: docker.io/karmawow/experiment:proxy-0.2
        name: traefik-forward-auth
        ports:
        - containerPort: 4181
          protocol: TCP
        args:
          - --rule.user.action=auth 
          - --rule.user.groups=AppStage 
          - --rule.user.groupmode=any
        env:
        - name: PROVIDER_URI
          value: https://keycloak.team.stage.company.com/auth/realms/internal-users
        - name: CLIENT_ID
          value: proxy
        - name: CLIENT_SECRET
          valueFrom:
            secretKeyRef:
              name: traefik-forward-auth
              key: CLIENT_SECRET
        - name: SECRET
          valueFrom:
            secretKeyRef:
              name: traefik-forward-auth
              key: SECRET
        - name: AUTH_HOST
          value: auth.team.stage.company.com
        - name: COOKIE_DOMAIN
          value: team.stage.company.com
        - name: DOMAINS
          value: team.stage.company.com
       # - name: GROUPS
       #   value: AppStage
       # - name: GROUPMODE
       #   value: any

</details>

[themooer1]

@cheald You fork works great! Thanks!

I started automated docker builds of @cheald's fork here: https://github.com/themooer1/traefik-forward-auth/pkgs/container/traefik-forward-auth

I'll keep them hosted there until I or someone else generalizes the groups check to support any claim and opens a pull request.