Forward Proxy authentication - OIDC Groups

[mitchplze]

Can you start a new discussion for OIDC groups? I am probably missing something (or trying to to multi-task) and not sure why relabeling groups is even needed.

Originally posted by @amir20 in #4118 (reply in thread)

---

Hello,

Currently the Client-Role (customizable) authorization header in Dozzle expects a specifically-formatted value like: roles:shell|actions|download. This means one has to write a custom reverse-proxy rule to create and then inject a new header on authentication, with data sourced (most likely) from a custom OIDC claim that also has to be created and maintained separately, and you have to remember the formatting/options.

Currently:

• Plus + a proxy rule to then create that header and inject it.

Rather than do that, I think Dozzle should instead inspect the forwarded header value for 'tags' or keywords, so that existing OpenID group claims can be passed seamlessly through the proxy, to Dozzle, as an existing header (X-Forwarded-Groups in a lot of cases).

That header should already look like an array: ["group1","group2","group3"]

So my proposal:

Example:

- DOZZLE_AUTH_PROVIDER: forward-proxy
- DOZZLE_AUTH_HEADER_USER: X-Forwarded-User
- DOZZLE_AUTH_HEADER_EMAIL: X-Forwarded-Email
- DOZZLE_AUTH_HEADER_NAME: X-Forwarded-Preferred-Username
 
- DOZZLE_AUTH_HEADER_GROUPS: X-Forwarded-Groups   # Tells Dozzle the header that contains OIDC groups from IdP
- DOZZLE_AUTH_GROUP_ACTIONS: dozzle_actions   # Dozzle will map this tag/group to 'actions' privs
- DOZZLE_AUTH_GROUP_SHELL: dozzle_shell   # Dozzle will map this tag/group to 'shell' privs
- DOZZLE_AUTH_GROUP_DOWNLOAD: dozzle_download   # Dozzle will map this tag/group to 'download' privs
...etc 

Then one simply creates those groups on their identity provider, and adds the users to the appropriate groups.

Example with above config:

• Admin sets up a new user in the SSO provider and adds them to some groups.
• When the user logs in, Dozzle sees the X-Forwarded-Groups header from the SSO provider as: ["dozzle_actions","dozzle_shell","git_maintainer","something_else"]
• Dozzle sees the user is a member of the defined groups for actions and shell - but not download. Those privs are granted on login.
• If the user is removed from those groups in the future, the next logon, those privs aren't in the header, and are stripped.
• No customizations to the reverse proxy config are required at all. Just tell Dozzle which header, and what groups mean what.

If you don't want that level of granularity, one could just map them all to the same group:

- DOZZLE_AUTH_HEADER_GROUPS: X-Forwarded-Groups   
- DOZZLE_AUTH_GROUP_ACTIONS: dozzle_admins
- DOZZLE_AUTH_GROUP_SHELL: dozzle_admins
- DOZZLE_AUTH_GROUP_DOWNLOAD: dozzle_admins

So: ["dozzle_admins","something_else"] would grant the user all the privileges on login, as the same group is used for all.

Maintaining the current functionality of "no header = all privs" is a good one (if not a bit unsafe), if people don't want to bother setting this up at all - it would be very simple, and no additional vars.

Hope that makes sense. I'm away for a few days but will reply mid next-week.

[dima-bzz]

What if we simplify it by having a single env var for mapping groups to permissions?

For example:

DOZZLE_RBAC=admin=all,develop=actions|shell

This way we wouldn’t need separate variables for each role, and it would be easier to manage mappings in one place.

[dima-bzz]

Perhaps we could simply add a dozzle_ prefix as an alternative for roles.
If someone doesn’t want to create separate groups like actions, shell, or download, they could create a group such as dozzle_shell.
Then roles could be either shell or dozzle_shell. The groups can be passed to roles via SSO by configuring:

DOZZLE_AUTH_HEADER_ROLES: X-Forwarded-Groups

This way, Dozzle reads the user’s SSO groups from the header and automatically assigns the corresponding roles on login.

[amir20]

Thanks @mitchplze for the explanation. I don't think I understood the first time. But your examples of what an admin would do helped a lot.

So I see multiple things being asked here:

1. Support arrays in header instead of | separated strings. That's a fair ask and it can easily be supported with a simple JSON parse.
2. Support X-Forwarded-Groups by default. Currently, DOZZLE_AUTH_HEADER_ROLES is default to Remote-Roles. But this is already implemented as @dima-bzz pointed out.
3. Be able to remap group names to custom ones. I don't think should be done at the header level. This should be a configuration that can be either in users.yml or env variables.

I prefer defaults that would just work. So if it's just adding dozzle_ as an option then does that work? That would be pretty easy and it would reduce extra configurations that needs to be documented.

What do you all think?

[amir20]

#4150 supports json, comma and pipe. Addresses first issue above.

[amir20]

@dima-bzz I think there is a bug right now. It's actually comma separated and not |. 🤨

[dima-bzz]

@amir20 This was probably taken from our earlier discussion about how to handle roles.

[amir20]

#4150 should fix it.

[dima-bzz]

You could implement it like this:

...
switch role {
case "shell", "dozzle_shell":
    roles |= Shell
case "actions", "dozzle_actions":
    roles |= Actions
}
...

Or using a map for more flexibility:

...
var oidcGroupToRole = map[string]Role{
    "dozzle_shell_group":    Shell,
    "dozzle_actions_group":  Actions,
    "dozzle_download_group": Download,
}
...
switch r {
case "all":
    return All
default:
    if gr, ok := oidcGroupToRole[r]; ok {
        roles |= gr
    } else {
        log.Debug().Str("role", role).Msg("ignored unknown role/group")
    }
}
...

This way you can easily map multiple group names to roles and handle unknown roles gracefully.

[mitchplze]

Yes, that would be great!

So long as we ignore the rest of the header for groups/values that don’t start dozzle_

(because all the users groups are sent in the authorization)

[amir20]

So long as we ignore the rest of the header for groups/values that don’t start dozzle_

I still have to respect the regular ones like download, shell, etc... but only dozzle_ will be checked in addition.

I've made these changes with #4153. It's pretty simple. At this point you should have everything. Can you try amir20/dozzle:pr-4153?

• JSON syntax should be already allowed in master.
• You can still change the header of choice using DOZZLE_AUTH_HEADER_ROLES.
• Finally, with pr-4153 all roles with dozzle_* also get picked up.

[amir20]

@mitchplze did you test?

[mitchplze]

@amir20

dozzle:pr-4153 works as discussed, thanks!

[amir20]

great. going to release.