Feature request: OIDC

[0dragosh]

It would be great to have OIDC available as a login option so we can integrate any SSO we want.

[nicotsx]

Working on this

[0dragosh]

Awesome! I myself am using Pocket ID if that's important at all.

[dazzag24]

+1

Be great to use https://github.com/tailscale/tsidp with this.

[tvarohohlavy]

@nicotsx Whats your idea about implementing this?

I was thinking about proposing a base for RBAC implementation, basically just adding a role defaulted to admin into the users table so later there can be more users with other roles or more granular permissions via some custom roles, whatever. OIDC would either map to local users with assigned roles or later better pass a group or tag, that would identify that role.

Let me know if you would want any help.

Thanks and looking forward to it!

[nicotsx]

@tvarohohlavy I think I'll implement better-auth as suggested in #286 this will allow us to one shot the OIDC & 2FA features without writing / maintaining it

[nicotsx]

Hello, I have a working implementation of this and would like to confirm with you the flow and make sure this works for the use case.

1. User creates and validates a new sso provider from the settings page
2. User "link" their account. They click on "link account" and they are presented with the oauth flow. once completed the user they did the sign in with is linked (they can login either with sso or their creds)
3. On login page, a new button for each sso configured appears to login with
4. They have the option to disable the username/password access in settings after

[0dragosh]

I really like that the migration and user linking is presented to the user, normally in other apps the override is done purely in the DB and you don’t know which is which.

Having said that, I’d really much rather configure OIDC from env vars, at least me personally. Then the migration of an existing user can pick up from step #2 at first login as you said.

[nicotsx]

Thank you @0dragosh How would you configure multiple OIDC via env vars?

[tvarohohlavy]

Regards the usage, usually you have either credentials or SSO and in special circumstances you can have both. But its not usually meant for the admin user.

Admin sets up SSO providers. Users can then use them as you mentioned or even during registration. Both methods need basic role based access control to differentiate at least admin from others. If SSO is setup during registration so without password, afmin needs to move the user from no rights to some.

[0dragosh]

Thank you @0dragosh How would you configure multiple OIDC via env vars?

I think just plain env vars like so would be fine:

• OIDC_CLIENT_ID
• OIDC_CLIENT_SECRET
• OIDC_ISSUER_URL
• OIDC_CALLBACK_URI

This is also where some offer the ability to configure scopes and jwks uri and such through more env vars but I think that’s too verbose of a demand from the user, at least at first, and should be harcoded/inferred.

I also agree with @tvarohohlavy with regards to the flow and RBAC.

[nicotsx]

I think just plain env vars like so would be fine:

• OIDC_CLIENT_ID
• OIDC_CLIENT_SECRET
• OIDC_ISSUER_URL
• OIDC_CALLBACK_URI

This is also where some offer the ability to configure scopes and jwks uri and such through more env vars but I think that’s too verbose of a demand from the user, at least at first, and should be harcoded/inferred.

I also agree with @tvarohohlavy with regards to the flow and RBAC.

Good but this is only for one provider, how do you define multiple?

For the RBAC stuff this is not yet on the table, I'm not planning to add multi user support in the very near future. Will do later but for now it is just to allow you to log in as admin with your sso

[0dragosh]

Is multiple OIDC providers simultaneously so important though? Why isn't just one OIDC provider enough?

I've rarely seen this implemented in other apps.

I can't help but feel like this adds unnecessary complexity. I'm not the maintainer though :)

[nicotsx]

It's not that it's not enough but I will certainly find someone that will ask for a second or 5 more haha. And if we have committed to the generic env var we are stuck to add more, we have to release a breaking change

[tvarohohlavy]

Its a question wheter OIDC is important for someone if its just for admin.

[tvarohohlavy]

Regards config via Env you can check OIDC_CONFIG_1 to OIDC_CLIENT_N and expecting standartized JSON in it or even similar from docker secrets. Or the individual env vars just with counter from 1 to N.

Better Auth requires basically 5 vars per provider and rest is automatic so it can be done dynamically.

Or it can be done via import from json via the import feature.

[nicotsx]

Admin sets up SSO providers. Users can then use them as you mentioned or even during registration. Both methods need basic role based access control to differentiate at least admin from others. If SSO is setup during registration so without password, afmin needs to move the user from no rights to some.

After playing the whole evening with the implementation, I think you're correct @tvarohohlavy it would make sense to release the multi-users setup at the same time with some basic RBAC. The hassle to scope a whole OIDC provider to one user is complicated and not worth it considering we want to support multi users long-term. Now a very important question that I'm not sure I have the answer.

Should we link every entity (volume, backup, repo) to a specific user and each user manage their own backups or are all users sharing the same pool of ressources with different permissions? I'm interested to get your opinion @0dragosh @tvarohohlavy. What would be the benefits of one over the other?

[0dragosh]

A multi user setup implies RBAC and roles and all that, so users have their own backups and repos but roles can be granted that allow for users/groups to view/edit other backups.

I myself only have one use case, login as admin with a single SSO provider.

[tvarohohlavy]

I think this is the minimum so it can be extended later on with teams, direct user assignments, roles, specific rights.

At this point user without org membership would not have anything in ui, with membership he would have full access to all with org_id tag he belongs to.

Resources would be tagged with 1+ org:id tags or org:* for shared to all, but not for users without any org.

Most dificult to implement is propably the Authorization(AuthZ) engine.

Initial:

flowchart TB
  SA[System Admin]
  U[User]

  Org[Organization]
  Mem[(Org Membership)]

  Res[Resource]
  Tags[(Resource Tags: org_id* or org_all)]

  SA -->|creates| Org
  SA -->|creates| U
  SA -->|assigns| Mem

  U -->|belongs to| Mem
  Mem -->|grants access to| Org

  Org -->|context for| Res
  Res -->|is tagged with| Tags

Later on with roles:

flowchart TB
  SA[System Admin]
  U[User]

  Org[Organization]
  Mem[(Org Membership)]

  Role[Role]
  Perm[(Allowed Action)]

  Res[Resource]
  Tags[(Resource Tags)]

  SA -->|creates| Org
  SA -->|creates| U
  SA -->|defines| Role
  SA -->|assigns| Mem

  U -->|belongs to| Mem
  Mem -->|selects| Org
  Mem -->|has| Role

  Role -->|allows| Perm

  Org -->|context for| Res
  Res -->|is tagged with| Tags

  U -->|requests action| Perm
  Perm -->|applies to| Res

[e1ke]

Great to see that you guys are working on SSO OIDC! Just throwing in that I would use it for only one OIDC Provider (Authentik) and would like to map the 'groups' so I can allow specific groups to have permission on specific repos / snapshots in zerobyte. Thx for your great work so far!